[pulseaudio-discuss] Per-application volume glitching, and an idea for multiple channel volume control

[Lennart Poettering]

On Sun, 21.12.08 13:32, Jud Craft (craftjml at gmail.com) wrote:

> Hello there!  I've noticed a peculiar symptom using Pulseaudio
> (0.9.13) on Fedora 10.  Particularly this is related to
> per-application volume.  In a nutshell:
> 
> 1.  The "system sounds" entry in pavucontrol pays no attention to what
> volume level you set for it:  on my system, it consistently resets
> itself to 50%, and at random, jumps up to 100%.  This causes some
> system event sounds to be too quiet while others are obnoxiously
> loud.

Hmm, if you comment the line "load-module
module-position-event-sounds" in /etc/pulse/default.pa and
logout/login, does this problem go away?

> 2.  System sounds themselves seem to disregard this and play at
> different volumes anyway.  For example, the "dialog-cancel" sound,
> when a dialog box is closed or cancelled, is a giant "thump!" several
> times louder than the default close-window sound.  (I recall reading
> somewhere that a "libcanberra" is responsible for system-event-sounds,
> so perhaps the error lies there).  The login sound varies on its own
> from obscenely loud to randomly soft.

That sounds more like an issue with the sound theme in question:
i.e. the sounds used are not normalized to the same volume.

> 3.  Applications tend to forget their per-audio settings (this may be
> related to an earlier post I read on the December 2008 posts, where
> streams that change between mono and stereo may possible reset their
> volume levels, and another one from June 2007, where some crazy X
> session voodoo may prevent Pulseaudio from remembering per-app
> settings.  But I had hoped this was fixed.).

It is fixed now in PA git. We now try to remap volumes somewhat more intelligently.

> As a suggestion, it would be useful if Pavucontrol had a "Previous
> Applications" tab which displayed the levels of previously encountered
> streams/programs, and let you change the volume there.  (Pulseaudio
> seems to notice a program ONLY when it plays a sound, and in the case
> of Pidgin for example, many sounds are too short to reach Pavucontrol
> in time to change settings.  Compare Windows Vista, where a program's
> sound settings are persistently shown in Volume Control, even when the
> program is silent.)

Hmm, Short sounds are usually event sounds. And for event sounds we
now do have a seperate always visible volume control slider.

Pidgin should use libcanberra to play event sounds.

> Also, in regards to #3 (the mono/stereo thing), the post that I found
> on the mailing lists earlier mentions that PulseAudio will have an
> intelligent algorithm to adjust the volume when a stream switches from
> Mono to Stereo.  This seems a little counterintuitive, as it always
> means there will be some information loss when going from Mono to
> Stereo.
> 
> You'll notice that Windows Vista doesn't suffer from this problem,
> since it doesn't expose different channels at all:  each source has
> only one master volume control for that whole source, ignoring
> per-channel volume.

The logic we have in place now should behave exactly like this if the UI
decides to show only a single volume slider for each stream/device. In
fact the new gnomne-volume-control only shows a single slider now.

> I think this is a smart thing:  should it be PulseAudio's job to
> figure out the channel arrangements of every app?  But if it should,
> then how about the following idea:  what if Pulseaudio exposed two
> things.
> 
> 1) A master volume control for each source, similar to Vista, that is
> channel-agnostic
> 
> 2) A separate set of channel values, which are relative scalar to each
> other.  So a user can set a balance between the different channels
> (say, 25% left, 100% right), and still control the overall volume
> using a single slider;  this allows him to set a balance for the
> channels using the full slider range that is independent of the actual
> intensity of sound coming from the channel.

The current git version of PA supports Vista-style "flat volumes",
i.e. where the stream volumes are always forwarded to the device
volumes. However, that works only if the device provides us with
information about the dB range of its mixer controls. Volume
percentages are completely artificial and every driver/card/system
maps them differently to the actualy volume. So this will never work
on all systems (particaularly not on Bluetooth and suchlike which only
export integer volume levels)

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4