[pulseaudio-discuss] No volume control for audio from java applet in browser (pulseaudio-discuss Digest, Vol 26, Issue 61)

Tue Jul 2 16:34:35 PDT 2013

On Fri, Jun 28, 2013 at 6:52 AM, Alexander E. Patrakov
<patrakov at gmail.com> wrote:
> 2013/6/28 Andrew Skretvedt <andrew.skretvedt at gmail.com>:
>> I launched the WebSDR site in browser (http://radman.no-ip.com:8901/)
>> and icedtea (version 1.3.2) fired and audio was soon heard. It's too
>> loud by default on my setup, and this site's specific applet revision
>> provides no volume control (some newer WebSDR sites have more
>> control). So I must resort to dragging the soundcard sliders under the
>> output devices tab of pavucontrol down from their usual position at
>> "base" (63%/-12dB) to quiet the audio for the reasons already
>> mentioned.
>
> Possibly, this is yet another case of flat-volume related surprise
> behaviour. Please erase the volume database in .pulse and also try
> whether this line in /etc/pulse/daemon.conf helps:
>
> flat-volumes = no
>
> If this line doesn't help or is not needed, we need to debug further,
> please ignore the rest of the mail.
>

Results:
(1) I signed out of Openbox and removed the .pulse folder and
.pulse-cookie file from my home folder from a console login, then
signed back into an Openbox session. No changes in behavior were
observed from that mentioned in my prior post.

(2) I put the "flat-volumes = no" line into /etc/pulse/daemon.conf
next. Refer back to my prior post for full details on the prior
behavior I observed. Now, the flat-volumes=no line didn't resolve my
primary concern (why no playback volume slider for java?), but does
change the volume control behavior of the java audio, and decouples
the java audio from being strangely adjusted whenever I adjusted the
pavucontrol playback slider(s) for any other application outputting
audio. The java audio is left alone at its initial volume. I guess
that's an improvement (I consider it a bug, or something, that I could
manipulate the java audio by sliding the playback slider for deedbeef,
say).

> Note: because my IcedTea plugin does not use PulseAudio directly
> (probably due to some misconfiguration) and instead goes through the
> default ALSA device (apparently, with software attenuation), I cannot
> reproduce the bug on my Gentoo system on http://radman.no-ip.com:8901/
> .

Apparently, in my system, the Adobe Flash plugin seems to try to use
ALSA too, but I think my configuration wants to catch such an attempt
and redirect that access through some kind of wrapper (?) so it can
then be handled by PulseAudio like any other stream. The attached
screenshot demonstrates what happens when I start a YouTube video
playing. If that's what's happening, I think that's great! So...I will
investigate if it's possible to reconfigure icedtea java to use alsa
instead of Pulse, and see if I would get the same behavior I'm getting
for Flash. That would solve my primary concern, and would seem to
demonstrate either a bug in Pulse, or a bug in java's use of Pulse. Do
you have any thoughts on that?

> <troll>
> If the flat-volumes = no line does help (which we still have to
> confirm), the bug can be dissected as follows:
>
> 1. Pulseaudio, when running in flat-volume mode, makes two unrelated
> changes to volume handling:
>
>  (a) The mixer API starts accepting volumes relative to the hardware
> maximum of the card (I call that "absolute" volumes below), not
> relative to the volume set by the master mixer control. There is no
> other PCM stream attenuation API in the world that does such thing.
>  (b) The hardware mixer is set to the maximum of the playing streams'
> absolute volumes, the rest of streams are attenuated in software. As
> opposed to providing a separate master volume control that directly
> controls the hardware mixer.
>

Ok! I think (1b) must be what's happening to me occasionally when I
notice, just by starting another program with audio output, sometimes
the sound card's volume on the Output Devices tab will jump up off
'base' (where I like to keep it) to some higher level. I'm always
caught off-guard when that happens, and usually shocked by the sudden
overly loud audio for everything. I much prefer the treatment in
Windows Vista/7, which I also run and which you demonstrated with a
screenshot in another post. Is that behavior (1a)? I would rather
Pulse behave that way. I don't like it when I explicitly set an output
device volume, and then the software overrides my choice, and also
does it in a way that feels counter-intuitive. (My audio hardware is
capable of massively overdriving my builtin speakers; the 'base'
setting prevents that.)

> 2. Pulseaudio trusts the clients when they set their volume.

Hmm, maybe that's not a good idea. In Win Vista, if I reduce the main
slider to some level well below output device maximum, no
application's output can go above that level. This makes intuitive
sense to me, otherwise why even have a slider for controlling the
output device directly?

>
> 3. Buggy clients set volume to 100% because they assume (e.g. based on
> the author's experience with Windows or with Ubuntu, where flat
> volumes are disabled) that this is relative to the master control.
>

Yeah.

> So, from a formal viewpoint, there is nothing to fix in pulseaudio
> here - it is an IcedTea bug that it does not properly virtualize (i.e.
> convert from relative to absolute, when pulseaudio is running in
> flat-volume mode) volume changes done by the Java applications.
>

Perhaps, however...gosh I'm just not sure if my IcedTea java really is
using PulseAudio for its output, or what it's doing. It appears
configured for pulse. There's no exclusive lock on my audio hardware
when java plays audio, yet there's no playback slider. I need to learn
more I think in order to properly test how java's configured. I'll try
the ALSA idea I mentioned above and report.

> However, there is a similar gstreamer bug, and similar surprise-volume
> Epiphany bugs caused by HTML5 (where in-browser content has no way to
> know that it sets absolute, not relative, volume):
>
> https://bugzilla.gnome.org/show_bug.cgi?id=680779
> https://bugzilla.gnome.org/show_bug.cgi?id=696317
> https://bugzilla.gnome.org/show_bug.cgi?id=675217

I checked some of these...yes, these surprises happen to me too (ooh
and I hate them). But I guess with flat-volume=no, this won't happen,
and behavior will be similar to Win Vista/7? (which I'd prefer, as it
seems more intuitive to me)

>
> and in the past there were many more duplicates. So, maybe this
> duplicate will finally cause the developers to reconsider point 1a.
> Note: I have nothing against 1b (assuming that overamplified streams
> clip at the master volume), this just makes "master" a software-based
> control that is mapped to nothing in hardware, and the hardware mixer
> is controlled automatically.
>
> </troll>
>

So with (1b) the idea must be to deprecate a user's reliance on using
the output device's volume slider, and instead rely on volume controls
provided by the application. Let me see if I understand this: Say the
output device's volume is initially set to 50%. You start a conforming
application and it's volume is set to 25%. PulseAudio will treat this
as 25% of full hardware volume, not 25% of the 50% you'd set for the
output device. So Pulse will bump the output device volume until the
app's output becomes 25% of full hardware capability?  I'm actually
very confused as to how (1b) works. I think I'd need a tutorial video.
Do you think average users get it?

We're starting to cover a lot of ground here. Thanks especially Alex,
and also Tanu, for your efforts!

-Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2013-07-02--1372803506_1024x768_scrot.png
Type: image/png
Size: 192483 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20130702/1b2a8685/attachment-0001.png>