My computer's system volume is usually set around 25%, which is fairly loud. Whenever I open a page in webkitgtk (via Epiphany) with an html5 video, the player automatically sets its volume to 100%. This in turn drags the system volume up to 100%, resulting in me blasted and frantically reaching for the volume knob in an effort to save my ears. In case it's helpful, my system does use pulseaudio, and I can reproduce this behavior with other gstreamer apps (e.g. rhythmbox) by dragging their application volume knob up to 100%. This makes me think that this is the expected behavior when setting an application's volume to 100%. Therefore, it seems to me that it is wrong for the webkit player to set its volume to 100%.
Right, I'll look into it tomorrow, thanks Jonathon for reporting this issue!
I tracked down this issue to gstreamer's pulsesink :/ Can you try this in command line? This is more or less the equivalent of what our player does and I can reproduce the volume issue with this: gst-launch-0.10 playbin2 volume=1 uri=file://.... Removing volume=1 fixes the problem
Created attachment 82119 [details] proposed patch Can you test this workaround? I believe the real issue is either in pulsesink or PulseAudio itself :/
Comment on attachment 82119 [details] proposed patch Seems reasonable. I guess it just limits when the bug occurs.
(In reply to comment #2) > I tracked down this issue to gstreamer's pulsesink :/ > Can you try this in command line? This is more or less the equivalent of what our player does and I can reproduce the volume issue with this: > > gst-launch-0.10 playbin2 volume=1 uri=file://.... > > Removing volume=1 fixes the problem Yes, I can reproduce with that command line. That's the same case as I was talking about in my initial case where increasing the rhythmbox application volume slider to 100% also drags the system volume upw ith it. And my suspicion is that this is how pulseaudio is *supposed* to work (e.g. I wouldn't be surprised at all if the gstreamer/pulse guys said that this is not a bug). I think the workaround is actually more harmful than good. Because initially it'll start out at a normal volume (with system volue set at ~25%), but if you try to adjust the volume down slightly in the webkit player (e.g. to ~90%), your system volume will suddenly be set to 90% and you'll get blasted even though you were trying to reduce the volume. Or do I misunderstand the patch?
OK, I just talked with some gstreamer / pulseaudio people and they confirmed that this is indeed how things are supposed to work. The system volume is always equal to the volume level of the loudest stream. What this means is that explicitly setting the webkit player stream to 1.0 will *always* set the system volume to the maximum value. This is clearly very bad when it happens automatically at startup. Looking at the html5 spec for audio volume, I notice that it says: "Initially, the volume must be 1.0, but user agents may remember the last set value across sessions, on a per-site basis or otherwise, so the volume may start at other values". It seems to me that this allows browsers to ignore the initial volume and still satisfy the spec. So I see 2 basic options forward: 1) always treat the DOM volume property as a percentage of system volume. So for example, when the volume is set to 0.9, you need to read the system value, and then set your gstreamer stream volume to 0.9*system. 2) Ignore the initial 1.0 value at startup and instead set the DOM value of your volume property to the current system volume. Setting the volume to 1.0 will still result in very loud audio, but if the user can see that the volume is currently at 0.25 and they still drag the volume slider all the way up to 1.0, they will expect it to get much louder. Option 2 seems to be the way that all other gstreamer clients behave (e.g. totem, rhythmbox), the only difference being that those applications don't change the volume unless the user requested it, so the user knows what to expect.
In playbin the default volume is 1.0 anyway. What's not normal is that nevertheless if we explicitely set it to 1.0 the global volume jumps to 100%. This should not happen IMHO.
Created attachment 82313 [details] updated patch
Created attachment 82327 [details] updated patch
Comment on attachment 82327 [details] updated patch Seems sane.
Committed r78571: <http://trac.webkit.org/changeset/78571>
I've now tested this patch, and while it certainly improves things, it does exactly what I predicted it would do in comment #5. When the video starts, it doesn't set the stream volume to 1.0, which means that the video starts playing at a sane volume and does not blast my ears. So far so good. However, even though you didnt' set the gstreamer stream volume to 1.0, the value of the volume DOM property is still set to 1.0, so the player still believes that the volume of the stream is set to 1.0. Because of this, the player's volume slider control is shown at its highest level. Now imagine that I want to reduce the volume of the video slightly, so I drag the volume control slider down a bit (to ~80% or something). Suddenly the gstreamer stream volume gets set to 0.8 and I get blasted by really loud volume again even though I actually dragged the volume control *down* instead of up. So while this patch improves things in one situation, it's certainly not a complete fix for the problem.
(In reply to comment #12) > I've now tested this patch, and while it certainly improves things, it does exactly what I predicted it would do in comment #5. > > When the video starts, it doesn't set the stream volume to 1.0, which means that the video starts playing at a sane volume and does not blast my ears. So far so good. > > However, even though you didnt' set the gstreamer stream volume to 1.0, the value of the volume DOM property is still set to 1.0, so the player still believes that the volume of the stream is set to 1.0. Because of this, the player's volume slider control is shown at its highest level. > What's your use-case exactly? I can indeed reproduce the issue you mention with the vimeo player but not with pages using the native controls, like http://www.w3.org/2010/05/video/mediaevents.html With the page above you indeed should see the initial volume as 1.0 but once playback starts, pulsesink notifies our player of the restored stream volume value and the DOM property is update accordingly, the volume slider is not stuck at 1.0 then.
Please open a clone of this bug if needed. We usually don't reopen bugs unless the patch is rolled out, which is not the case here.
(In reply to comment #14) > Please open a clone of this bug if needed. We usually don't reopen bugs unless the patch is rolled out, which is not the case here. OK, sorry for that.
(In reply to comment #15) > (In reply to comment #14) > > Please open a clone of this bug if needed. We usually don't reopen bugs unless the patch is rolled out, which is not the case here. > > OK, sorry for that. Did you open a new bug? I think we should make sure the DOM value is set even before pulsesink notifies us.
I finally did clone this bug. Sorry for the huge delay. But it's still easily reproducible in epiphany. see Bug 118974