Comment 9 for bug 1504065

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

To expand on Michał's hypothesis...

1. You connect a headset for which the remembered "alert" volume < 85 dBA, but "multimedia" volume > 85 dBA.
2. You start playing a video, so the active audio output role switches from "alert" to "multimedia".
3. Since the "multimedia" volume > 85 dBA, the snap decision appears.
4. Since the video has lost focus, it stops playing.
5. Since the video has stopped playing, the active role switches back to "alert".
6. Since the active audio output role is no longer one with volume > 85 dBA, the snap decision disappears.
7. You're left with nothing but a paused video.

If so, there are a few possible solutions, not mutually exclusive...

(1) Perhaps Ubuntu should clamp all restored volumes to 85 dBA? But that might be annoying if you accidentally unplugged a headset for a couple of seconds, plugged it back in, and had to re-amp the volume.

(2, 5) This particular symptom might be suppressed by merging "alert" and "multimedia", though it might still occur while bug 1485522 is unfixed (apps being allowed to override the system-set multimedia volume). Even if that was fixed too, though, you might get a similar problem if, for example, you had set the "alarm" volume to be greater than 85 dBA. Either the volume warning snap decision would suppress the alarm snap decision, and would immediately disappear because the alarm was no longer playing; or the volume warning wouldn't appear at all, because it couldn't appear until the alarm stopped, at which point it would no longer apply.

(4) It might be reasonable to pause video playback when a dialog appears in *some* cases -- for example, incoming call, alarm, or timer done. I doubt this is always true, though -- probably not for volume warnings, and certainly not for dialogs in general on a PC. Pause if you switch to a different app, sure, but not merely for a dialog on top of the current app.

(7) If video playback does pause for a dialog in general, maybe it should resume when the dialog goes away. But that seems unlikely; if loud music was interrupted by a 40-minute phone call, the call unexpectedly disconnecting shouldn't cause the music to suddenly blare in your ears. Anyway, changing that wouldn't fix this bug, it would just make it even worse by turning it into an endless loop.