kmix breaks pulseaudio volume per channel setup when changing volume to 100% or 0%

[Murz]

Binary package hint: kdemultimedia

I have setup pulseaudio 5.1 configuration with different volume per channel:
http://imagebin.ca/view/0wF1MTI.html
If I change volume via kmix tray icon, it change volume in each channel without breaking volume configuration.

But when I changing volume to 100% via kmix tray icon, it sets all channels to same volume!
And if I goes back to 50% all chanels have same volume too, so all my volume configuration lost!

And if I change volume to 0% I have the same problem.

I think that kmix must don't break pulseaudio volume configuration!

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: kmix 4:4.5.1-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Sat Oct 2 11:08:14 2010
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: kdemultimedia

[Murz (murznn)]

There are screenshots of configuration before and after setting 100% volume in kmix.

[Murz (murznn)]

Version: 3.7 (using KDE 4.5.2)
OS: Linux

I have use pulseaudio with Surround 5.1 speakers.
And I setup different volume per each channel for normal volume near computer, it looks like this: http://imagebin.ca/img/0wF1MTI.png
But when I change volume to 0% and 100% via kmix, and revert volume back to near 50%, kmix broke my volume configuration and do the same volume for each channel!
And after this channels volume looks like this: http://launchpadlibrarian.net/56971008/snapshot2.png

Via pactl command I see that each pulseaudio sink have per-channel volumes and base volume, for example in my situation it looks like this:
---------------------------------
Sink #1
        State: RUNNING
        Name: alsa_output.pci-0000_00_14.2.analog-surround-51
        Description: Internal Audio Analog Surround 5.1
        Driver: module-alsa-card.c
        Sample Specification: s16le 6ch 48000Hz
        Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe
        Owner Module: 1
        Mute: no
        Volume: 0: 28% 1: 27% 2: 30% 3: 30% 4: 33% 5: 21%
                0: -33.05 dB 1: -34.11 dB 2: -31.36 dB 3: -31.36 dB 4: -29.02 dB 5: -40.33 dB
                balance -0.02
        Base Volume: 63%
                     -12.00 dB
        Monitor Source: alsa_output.pci-0000_00_14.2.analog-surround-51.monitor
        Latency: 153185 usec, configured 156000 usec
        Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY
---------------------------------

And kmix changes volume of each channel:
        Volume: 0: 33% 1: 32% 2: 35% 3: 35% 4: 38% 5: 26%

But better is to change base volume of channel, because it didn't break anything!

I can do it manually via command
pactl set-sink-volume 1 [0-65535]
and it works very good.

So I think that kmix must switch to base volume changing instead of change volume for each channel in pulseaudio sink!

Reproducible: Always

OS: Linux (x86_64) release 2.6.35-22-generic
Compiler: cc

[Murz (murznn)]

Here is screenshot of my kmix window: http://img28.imageshack.us/img28/3052/21717927.png

[Colin Guthrie (launchpad-colin)]

Please right click on the slider in kmix and choose the "Split Channels" option (this could arguably be better exposed but that is something that is technically separate from the PA backend specifically - ideally I'd also like to label the different channels, but no framework inside kmix for this exists yet either)

[Murz (murznn)]

If I do the "Split Channels", I see all 6 channels in Kmix window, but when I change volume via mouse whell on tray icon, I have same problem! All channels goes to same volume after changing to near 0% and near 100%!

So, your method didn't solve the problem!

[Murz (murznn)]

This is the video that demonstrates the problem visually: http://www.youtube.com/watch?v=zjPbBd2CCzc

[Murz (murznn)]

Here is video that visualize this bug: http://www.youtube.com/watch?v=zjPbBd2CCzc
And I try Ubuntu fresh install, gnome volume applet don't breaks per-channel volume when setting it to 100%.

[Colin Guthrie (launchpad-colin)]

Thanks for the video. I'm not really sure what can be done about that however. pavucontrol itself behaves a similar way when using the mouse wheel. The kmix mousewheel slider integration (as with the keys on multimedia keyboards and laptops etc) are designed to give a nice, simple interface to volume adjustment. As soon as you break the "simple" controls (e.g. by controlling left and right channels independently), then that's the price to pay.

There are several different modes of operation here that would support a "fix" anyway. Keep the relative balance stored somehow, and "compress" the ratio as it gets to the upper limits and reinstate it when the volume is reduced sufficiently to allow it again is one method. Blocking any further volume increases is another.

I could do the latter in kmix itself probably (although I'm not certain of this as the decisions on the could actually be further up the kmix stack - can't remember off hand). The former would really have to be done in PA itself (doing "intelligent" volume handling as the PA client application level has a very nasty habit of creating "feedback loops" - the same thing happened with the initial Gnome volume control applet). But even if the first suggestion above was acceptable, the question of precisely what upper limit is presented also comes into play. At the moment, I only expose the 100% aka 0dB point in Kmix but there are people who want to expose up to ~150% (~+11dB). This is software amplification territory. The principles of how to present this are tricky but it's certainly the case that some users need this kind of extra boost. The way it's handled in gnome is inconsistent (the main application allowing up to 150% and the applet capped at 100% - presenting these concepts to the user is trick to say the least).

So I suspect that the first solution is the desired one, but with the added issues of upper bounds capping, the problem does get harder.

I'll certainly discuss the problem upstream and see if there is a general consensus on the issues involved.

[Murz (murznn)]

I check this issue in gnome and see that issue exists only on 0% volume, when changing volume to 100% it does not break per-channel configuration. Maybe kmix can do something like in gnome?

As workaround I can offer the method for 0% volume:
We can analyse new per-channel volumes before do the change, and if some of channel will have 0% volume, do the mute instead of decrease volume for each channel and breaking current per-volume config.

And about 150-200% we can add option for maximum channel volume in kmix, and do the change between 0 and this value.

[Murz (murznn)]

And I do some another checks via pulseaudio console utility pactl:
I can change the volume of sink via command
$ pactl set-sink-volume 0 10000 # volume is from 0 to 65535.

When I changing it to maximum value (65535), it don't break channel balance and set 100% volume only for channel with maximum level.

But when I set volume to 0, it breaks balance :(

I created the issue about this in pulseaudio tracker: http://pulseaudio.org/ticket/874

So, at now for solve 0% problem I see only the workaround from previous post, but for solve problem on 100% you can change the volume increase method in kmix to like in gnome.

[Colin Guthrie (launchpad-colin)]

Hmmm, yes, looking again the the gnome stuff, it is handled in a nicer way. It seems to scale the left+right balance better and blocks when one channel hits 100%. For me, when getting to 0 the balance got gradually more "even" and then muted, but scrolling up again seemed to retain the balance originally chosen. I'm not quite sure how this works, but I presume there is some kind of client side balance algorithm involved. I'll try and take a look at the code to see how that works.

So ultimately, for me at least, the gnome volume worked pretty much exactly how you suggest.

Incidentally the numbers you mentioned for volume are slightly incorrect. The 65535 value corresponds with 0dB aka 100% aka PA_VOLUME_NORM. The maximum volume is technically uint32(-1). Which is substantially larger than the 65k value. The GUIs and tools limit this upper range however, so it's not completely relevant here (there are reasons that it becomes relevant such as the exposure of volumes > 100% as previously mentioned - and this is a problem that is not yet solved on the Gnome side either FWIW).

[Murz (murznn)]

Thanks, I looking forward to new release, pleas inform about news :)

And one more idea: via pactl command in sinks I see the "Base Volume" value for each sink. Maybe we can change via api this volume to 0% and 100% without breaking per-channel setup?

But I can't found the way to change it via pactl to check.

[Colin Guthrie (launchpad-colin)]

The base volume is really not something that you can change. It's a product of what comes from the hardware. A lot of hardware does not provide this information and thus Base Volume == PA_VOLUME_NORM == 0dB == 100%

It is only really relevant for initial volume choices for new users and to display to the user that anything above the base volume can be subject to some degree of clipping/artefacts.

For reference, some documents about how to present volume sliders is present here:
http://pulseaudio.org/wiki/WritingVolumeControlUIs#Colouredvolumesliders

No-one has yet implemented such a coloured scheme (with the exception of VLC which uses a very similar mechanism, in it's native GUI, but with no direct relation to PA and base volumes. It also uses a completely different dB->percentage mapping to that used by PA)

[Colin Guthrie (launchpad-colin)]

Oh and with regards to keeping informed of the work I do, I suggest you follow either my own blog or Planet KDE as I usually blog about new things via this channel.

[Christian Esken (esken-kde)]

Yes. The topic of volume "balance" is a actually more complicated than one would assume. The issues are (as described in the former comments) how to handle "upper bound" and "lower bound", and also whether to store (internally and for persisting/restoring) absolute or relative (or both) values and possible issues with rounding for controls that do not use the range 0-100.
I think something like the "upper bound" handling like in Gnome can be done easily.

[B994265 (b994265)]

Unfortunately this problem still stands.

In Pulseaudio 8.0 there's a new API that could be used as a solution.

"There's a new API for controlling the LFE (a.k.a. subwoofer) channel volume relative to all other (except mono and aux) channels.

Some background: the "native" volume representation in PulseAudio is to have independent volume for each channel, but some UIs may prefer to have one "overall volume" slider and two sliders for controlling the left-right and rear-front balances. There have always been helper functions for mapping the left-right and rear-front balances to per-channel volumes and vice versa. The LFE channel is not included in any of the conversions, however. To allow users to also control the LFE channel volume some UIs (at least the Gnome sound configuration tool) have added the LFE channel control as a separate slider, but in practice that had weird interactions with the overall volume slider.

To resolve this problem, we now have helper functions for controlling the balance between LFE and non-LFE channels, which allow changing the balance without affecting the overall volume. All applications that present the left-right and rear-front balances to the user are advised to start using the new API for dealing with the LFE volume.

The new functions are pa_cvolume_get_lfe_balance, pa_cvolume_set_lfe_balance and pa_channel_map_can_lfe_balance."