Bugzilla

(In reply to Alastor Wu [:alwu] from comment #15)
> Is it benefit for all platforms? 

Yeah it must be beneficial for every platform, if we want to support it would be good to have it everywhere. The risk of unplugged or disabled devices on the desktop platforms is higher but again it would be more than good to have it everywhere.
 
> If the original device is closed during muting, I assume that we would route the audio to another available device when unmuting the audio? 

Yes, this is supported in all desktop platforms. However, many bugs have been discovered in that area and this is mostly because the devices out there are too many and unpredictable. For example, the notifications might arrive with a lag or in an unexpected order or a device can go silent without reporting an error, etc. Don't get me wrong, I am not against it, I just want to provide the full picture.

> Letting device being idle can reduce its battery usage, but I wonder if there is any drawback which might be caused by being idle?

The device will be stopped but not deleted. Which means we don't have to re-initialize it, just to start it. The stream is there, all the way down to the system level but the audio thread is not iterating. I am not sure if that means the same for every device/platform.

> How to verify if the audio stream is active or not, I would like to check how other browsers behave on this situation.

On Linux you can use `pavucontrol` a small tool to see the system streams. When the stream is stopped but not deleted, the stream is still listed but the visual indicator of the audio level remains inactive. When the stream is deleted, that stream disappears from the list. If you ping me we can go through an example together.

> What kind of solution you think we should do? should AudioStream call `cubeb_stream_stop` explicitly when the stream is muted? or we want to do something inside Cubeb?

If we added something in cubeb it will be equivalent to `cubeb_stream_stop` and it would create one more special case that any cubeb's client should know about. In addition to that, it would not sort out the whole situation. So my opinion is that it would not be in the right direction to put something in there. 

In my opinion when the volume goes to zero, we should call `cubeb_stream_stop` and when it is unmuted `cubeb_stream_start. In parallel we must be registered for CUBEB_STATE change callback. If a state error is reported, when in mute, probably (you might know better here) we must close the playback. Alternatively, if we are in the system clock so the user does not 'feel' the error, we can attempt to reinitialize the stream, without starting it. Also those state change callbacks, including the CUBEB_STATE_START and CUBEB_STATE_STOP on mute unmute respectively must not be handed to the AudioStream because it relies on those to make decisions about the state of the playback. In addition to that, we must have an alternative behavior if `cubeb_stream_stop` fails on mute, or `cubeb_stream_start` fails on unmute. In the first case, we could call the regular volume API. Btw this would increase the complexity to separate the case. In the second case, there is not much we could do. We can attempt to reinitialize the stream but it will take some time, and if that fails, I guess, the playback should fail/stop too. Feel free to add your thoughts on that.

For the device change, plug, or unplug cases the situation is better. In general, the way playback configures cubeb, it allows for the output device to change automatically to the next default, and to remain ready to be started. However, if the playback code needs to know the updated device id, there are more things to be done. Let me know if that's the case.

> Do we want to stop the stream whenever the audio becomes inaudible? or we want to have a time threshold, like the dormant mechanism in MDSM to avoid the possibility of opening/closing stream within a short period of time?

Well, I am not the best to comment on that depends on what you want. In general, it would make sense, it would reduce the risk since it would reduce the number of times the hardware is accessed with the cost of increasing the complexity.

(In reply to Alastor Wu [:alwu] from comment #15)
> Is it benefit for all platforms? 

Yeah it must be beneficial for every platform, if we want to support it would be good to have it everywhere. The risk of unplugged or disabled devices on the desktop platforms is higher but again it would be more than good to have it everywhere.
 
> If the original device is closed during muting, I assume that we would route the audio to another available device when unmuting the audio? 

Yes, this is supported in all desktop platforms. However, many bugs have been discovered in that area and this is mostly because the devices out there are too many and unpredictable. For example, the notifications might arrive with a lag or in an unexpected order or a device can go silent without reporting an error, etc. Don't get me wrong, I am not against it, I just want to provide the full picture.

> Letting device being idle can reduce its battery usage, but I wonder if there is any drawback which might be caused by being idle?

The device will be stopped but not deleted. Which means we don't have to re-initialize it, just to start it. The stream is there, all the way down to the system level but the audio thread is not iterating. I am not sure if that means the same for every device/platform.

> How to verify if the audio stream is active or not, I would like to check how other browsers behave on this situation.

On Linux you can use `pavucontrol` a small tool to see the system streams. When the stream is stopped but not deleted, the stream is still listed but the visual indicator of the audio level remains inactive. When the stream is deleted, that stream disappears from the list. If you ping me we can go through an example together.

> What kind of solution you think we should do? should AudioStream call `cubeb_stream_stop` explicitly when the stream is muted? or we want to do something inside Cubeb?

If we added something in cubeb it will be equivalent to `cubeb_stream_stop` and it would create one more special case that any cubeb's client should know about. In addition to that, it would not sort out the whole situation. So my opinion is that it would not be in the right direction to put something in there. 

In my opinion when the volume goes to zero, we should call `cubeb_stream_stop` and when it is unmuted `cubeb_stream_start`. In parallel we must be registered for CUBEB_STATE change callback. If a state error is reported, when in mute, probably (you might know better here) we must close the playback. Alternatively, if we are in the system clock so the user does not 'feel' the error, we can attempt to reinitialize the stream, without starting it. Also those state change callbacks, including the CUBEB_STATE_START and CUBEB_STATE_STOP on mute unmute respectively must not be handed to the AudioStream because it relies on those to make decisions about the state of the playback. In addition to that, we must have an alternative behavior if `cubeb_stream_stop` fails on mute, or `cubeb_stream_start` fails on unmute. In the first case, we could call the regular volume API. Btw this would increase the complexity to separate the case. In the second case, there is not much we could do. We can attempt to reinitialize the stream but it will take some time, and if that fails, I guess, the playback should fail/stop too. Feel free to add your thoughts on that.

For the device change, plug, or unplug cases the situation is better. In general, the way playback configures cubeb, it allows for the output device to change automatically to the next default, and to remain ready to be started. However, if the playback code needs to know the updated device id, there are more things to be done. Let me know if that's the case.

> Do we want to stop the stream whenever the audio becomes inaudible? or we want to have a time threshold, like the dormant mechanism in MDSM to avoid the possibility of opening/closing stream within a short period of time?

Well, I am not the best to comment on that depends on what you want. In general, it would make sense, it would reduce the risk since it would reduce the number of times the hardware is accessed with the cost of increasing the complexity.