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. (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. </troll> -- Alexander E. Patrakov
