Latest working kernel version: 2.6.24
Earliest failing kernel version:
I'm seeing this with 2.6.25-rc2, but it's likely that the problem was introduced in the 2.6.25 merge window.
Hardware Environment: Intel ICH7 / Pentium D desktop system
Software Environment: Debian unstable
If I slide the left/right balance control in KDE's mixer panel from the center to the left, nothing happens (volume on both speakers remains constant). If I slide it to the right, the master volume control moves down too and volume is decreased on _both_ speakers.
The balance control worked fine in 2.6.24.
00:1b.0 Audio device : Intel Corporation 82801G (ICH7 Family)
High Definition Audio Controller [8086:27d8] (rev 01)
Created attachment 15094 [details]
Output of alsa-info.sh
Issue is still there with -rc3.
Hardware is an Intel Desktop with Intel D945GCZ mainboard.
I have just bisected this issue to:
2134ea4f37d36addbe86d4901f6c67a22a5db006 is first bad commit
Author: Takashi Iwai <email@example.com>
Date: Thu Jan 10 16:53:55 2008 +0100
[ALSA] hda-codec - Add virtual master controls
This really looks depressingly similar to #9374 from the 2.6.24 cycle.
The commit reverted to fix that also added a virtual master control...
No, it's no regression. The fact is that you had no master control in the earlier version. Thus the mixer app chose another one as an alternative. Now in the latest version, you have finally the master control which is mono channel.
That is complete and utter nonsense.
The balance control worked with the previous version and does not work with the new version. My opinion is that having a working balance control is a lot more relevant than having some nonsense virtual master control.
From my PoV as a user this definitely _is_ a regression.
Why should I want a virtual mono master control?
If you have to implement some virtual master control, the least you can do is to make it stereo so I get proper balance control.
Of course, a change that would leave the mono master control, but ensure that the balance control in applications is linked to a proper stereo control would be fine with me too.
However, any change that results in a working balance control in applications to be changed to something that does not control the left/right balance is a regression.
You still have the working balance control. There is no change about it.
The master control is a new addition over other controls. And other controls aren't changed at all.
The problem is that damn kmix behaves too smart and tries to fool you. What you accessed was either Headphone or Front control although kmix showed it as if it were a master control.
OK. I tried some other applications (took some time until I found one with a balance control: audacious), and that worked.
After some googling I also found http://bugs.kde.org/show_bug.cgi?id=155063, so it seems that this is indeed a known issue in KDE. The BR even had a workaround that works for me: there's a (somewhat hidded) setting that lets you select which control kmix considers to be the master control and thus controls the balance. Changing that to PCM or front makes the balance control work again.
Sorry for being a bit aggressive, but from my PoV it was a regression and I had the feeling the issue was being ignored.