On Fri, 2013-06-28 at 17:52 +0600, Alexander E. Patrakov 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. > > 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/ > . > > [ebuild R ] dev-java/icedtea-7.2.3.9:7 USE="X alsa cjk cups > jbootstrap nsplugin nss pulseaudio source webstart -debug -doc > -examples -javascript -pax_kernel -systemtap {-test}" 0 kB > > <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. I'm not familiar with Windows myself, but IIRC the flat volume feature was inspired by Windows' volume handling. Am I totally mistaken, and Windows always caps the stream absolute volume to whatever the device volume is set to? > (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. > > 2. Pulseaudio trusts the clients when they set their volume. > > 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. > > 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. > > 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 > > 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. While I think applications never have a valid reason to set the volume to 100% without the user requesting it, I do agree that 1a is not a good default. I also have some reservations about 1b, because the required synchronization between hardware and software volume doesn't always work reliably, and never will. 1b is a nice thing to have when the synchronization works, though. We currently have three maintainers, out of which two (me and David) are against flat volumes, so perhaps it's time to change the default. -- Tanu
