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>
