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
