[Bug 653446] Re: kmix breaks pulseaudio volume per channel setup when changing volume to 100% or 0%
Bug Watch Updater
653446 at bugs.launchpad.net
Wed May 23 12:44:02 UTC 2012
Launchpad has imported 13 comments from the remote bug at
https://bugs.kde.org/show_bug.cgi?id=254793.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2010-10-20T21:10:27+00:00 Murz wrote:
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
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/4
------------------------------------------------------------------------
On 2010-10-20T21:16:36+00:00 Murz wrote:
Here is screenshot of my kmix window:
http://img28.imageshack.us/img28/3052/21717927.png
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/5
------------------------------------------------------------------------
On 2010-10-20T22:44:09+00:00 Ym8-colin-nbv wrote:
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)
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/6
------------------------------------------------------------------------
On 2010-10-21T07:17:59+00:00 Murz wrote:
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!
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/7
------------------------------------------------------------------------
On 2010-11-06T10:05:35+00:00 Murz wrote:
This is the video that demonstrates the problem visually:
http://www.youtube.com/watch?v=zjPbBd2CCzc
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/8
------------------------------------------------------------------------
On 2010-11-08T10:14:35+00:00 Ym8-colin-nbv wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/10
------------------------------------------------------------------------
On 2010-11-08T10:48:43+00:00 Murz wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/11
------------------------------------------------------------------------
On 2010-11-08T11:07:08+00:00 Murz wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/12
------------------------------------------------------------------------
On 2010-11-08T11:50:54+00:00 Ym8-colin-nbv wrote:
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).
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/13
------------------------------------------------------------------------
On 2010-11-08T12:10:22+00:00 Murz wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/14
------------------------------------------------------------------------
On 2010-11-08T12:34:32+00:00 Ym8-colin-nbv wrote:
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)
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/15
------------------------------------------------------------------------
On 2010-11-08T12:35:25+00:00 Ym8-colin-nbv wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/16
------------------------------------------------------------------------
On 2011-12-30T13:04:04+00:00 Christian Esken wrote:
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.
Reply at:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/comments/17
** Bug watch added: PulseAudio sound server #874
http://pulseaudio.org/ticket/874
--
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to kdemultimedia in Ubuntu.
https://bugs.launchpad.net/bugs/653446
Title:
kmix breaks pulseaudio volume per channel setup when changing volume
to 100% or 0%
To manage notifications about this bug go to:
https://bugs.launchpad.net/kdemultimedia/+bug/653446/+subscriptions
More information about the kubuntu-bugs
mailing list