[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 254793] Kmix broke per-channel pulseaudio volume setup when
From:       Colin Guthrie <cguthrie () mandriva ! org>
Date:       2010-11-08 9:14:39
Message-ID: 20101108091439.C7965742D5 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=254793





--- Comment #5 from Colin Guthrie <cguthrie mandriva org>  2010-11-08 10:14:35 ---
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.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]