[pulseaudio-discuss] No volume control for audio from java applet in browser

[Andrew Skretvedt]

On Wed, Jun 26, 2013 at 4:37 AM, Tanu Kaskinen
<tanu.kaskinen at linux.intel.com> wrote:
> On Tue, 2013-06-25 at 03:58 -0500, Andrew Skretvedt wrote:
>> Hello list, I have a playback volume control question:
>> I'm running Crunchbang Linux, Firefox 21, and icedtea for Java...
>>
>> I like to listen to WebSDR sites, which mostly use java applets for
>> their audio delivery. These play fine in my browser, but I get no
>> volume slider in pavucontrol's playback tab. So, the only control over
>> the volume of the java audio coming at me is by the slider for my
>> output device under that tab, which is suboptimal as it's controlling
>> volume of all audio globally on my machine. What I'd like is to just
>> be able to adjust the volume coming from the java applet, which
>> doesn't always provide its own volume control in the browser for users
>> of the WebSDR receiver to twiddle.
>>
>> Anyone know why the java applet's audio output is not causing a volume
>> slider to appear in the playback tab? Other applications (all that
>> I've ever used, anyway: vlc, deadbeef, etc.) do cause sliders to pop
>> on as soon as they start emitting audio.
>
> The likely reason is that the java applet uses alsa directly. I would
> expect that if you have the java applet playing, nothing else can play
> simultaneously.

I conducted further tests to check your hypothesis about the java
applet/plugin using alsa directly:
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.

I next fired the deadbeef audio player and to check to see if the java
applet had grabbed the sound hardware exclusively via alsa. When
deadbeef came up and I selected a sound file to play, a slider
appeared (as normal) in the playback tab of pavucontrol, pre-set to
the previous level I'd left it. At this moment, the java applet's
sound output seem unaffected, but the deadbeef audio sounded unusually
loud given it's playback slider setting...the reason was that the
soundcard's sliders under output devices had suddenly jumped up to 84%
from 36% (as set in the prior step above).

If I dragged the soundcard's output slider back down to "base" where I
usually leave it, deadbeef's output level dropped back to the level I
normally like it (corresponding to the level I usually get with that
combination of hardware output volume, application playback slider
volume, and deadbeef's own in-program volume control.

At this stage the java applet's audio was now also back down to a
comfortable level (roughly corresponding to the level it'd been after
being forced to resort to dropping the soundcard level to 36% as
above). I noticed this strange effect:

Under pavucontrol, the java output was now coupled to the deadbeef
playback stream slider. When manipulated, the volumes of both audio
sources were affected. There was still NO slider offered for the java
output.

With this situation playing, I next started vlc with a movie playback.
This caused another playback stream slider to be generated (as
expected) with volume output as expected given where I'd last left
things in vlc.

Now, think about this...in pavucontrol, when I adjusted either the
deadbeef or the vlc playback stream sliders, the volumes for each of
those programs was affected independently (as expected), BUT the java
audio level was coupled to both. I.e. moving either slider up raised
the volume of the program it referred to AND java. Raising both
sliders in turn caused the volumes of each referenced program to
increase (expected), but java output was increased by the higher of
whichever of these sliders had been adjusted highest (in other words,
if vlc was raised from 24% to 53%, vlc's output and java's output
experienced gain; then if deadbeef's was raised from 24%, only
deadbeef's output would experience gain until 53%, after which both
deadbeef and java would experience gain while vlc would remain
steady).

If I stop playback in vlc and deadbeef, the control sliders in
pavucontrol remain, and can be manipulated to affect the java output
as I just indicated.

I can also go to the configuration tab and toggle the profile between
"off" and "analog stereo output" (my normal setting) and get different
effects. The audio of applications will cease, except for java, when
set to off. And depending on whether I've started to play media in
those other applications or not first before changing the profile, the
java output will either remain at a level commensurate with the
playback sliders as detailed above, or jump back up to the loud level
that had me reaching for these controls in the first place. I haven't
kept track yet of what combinations produce what results in this
regard just yet. When I return the profile to "analog stereo output",
the java volume, if it'd jumped up, will return back to its previous
lower level, and the output from the other media applications returns.

>From these results, I think I can conclude that:
1) the icedtea java plugin is indeed utilizing PulseAudio, as it seems
to be configured in it's sound.properties file (which also contains
comments indicating PulseAudio is the default setup). It doesn't seem
to be accessing alsa directly.
2) there is some anomaly with either or both of how icedtea is
accessing PulseAudio, and maybe how PulseAudio is treating java
3) this anomaly is causing java to be handled in unexpected ways with
regard to other audio output streams, as its volume control is not
explicitly enumerated, but somehow coupled with all of the other
presented playback streams

So...that's really weird, right?

There's obviously a bug somewhere, but where I cannot say.

A note about the hardware: this is an ancient HP/Compaq laptop model
nx9005 with 512MB RAM on a mobile AthlonXP processor. The audio is the
builtin ALi/ULi M5451 on an ALi/ULi M1535 chipset.

I don't expect a solution, I'm sure this is outside your normal scope.
But it is strange. I figure there is either a problem with the way the
hardware is being driven (audio seems to be OK otherwise), a problem
with icedtea's interaction with the audio subsystems at its disposal,
and/or a problem with the way PulseAudio is handling icedtea java.

At the very least, I think you have enough information to attempt to
replicate the behavior on other systems.

If software on a system using PulseAudio ignores this infrastructure
and accesses alsa directly, will this cause this behavior? Tanu's
first reply seemed to suggest the outcome would likely be that
PulseAudio would be blocked (along with any other applications
attempting to access the audio hardware directly). But, this isn't
what's happening.

Sorry for the length!

-Andrew