[kde-linux] 3.2.1 kernel upgrade - headphone volume no longer controlled by master

Duncan 1i5t5.duncan at cox.net
Sat Jan 14 05:16:34 UTC 2012


Mark Knecht posted on Fri, 13 Jan 2012 14:32:30 -0800 as excerpted:

> Title says most of it. I use headphones & not external speakers on my
> main KDE box. Up through gentoo-sources-3.1.5 the KDE master volume
> control has always adjusted headphone volume. With the 3.2.1 upgrade I
> did today it no longer does.
> 
> If I go all the way into the KDE mixer then the headphone control does
> control headphone volume so Alsa seems to have some control.
> 
> I tried the Select Master Channel and set it to Headphone but that
> didn't fix it.

That was exactly what I was going to suggest.  Did you try going back in 
and seeing if the setting actually took?  Maybe it didn't take for some 
reason (say hitting cancel instead of OK)?

Also, altho I don't know why this would work and it's exactly the type of 
thing that Linux users make fun of MS for, it's worth a shot.  Reboot, so 
you have a clean setup that hopefully doesn't have anything half-crashed 
or some such.  Check the setting.  If it's set to headphone, try setting 
it to something else and reboot again.  (If it's set to something else 
with the first clean reboot, skip that step.  Also, you can try simply 
restarting kde, tho that's not as thorough as a reboot.) Then set it back 
to headphone and reboot again, the idea being to get the setting to 
"take", without the possibility of something crashing in between.

Of course if that last thing works, there's certainly a bug as Linux 
users rightfully don't expect to have to do that sort of thing.

> Any idea on how to get this working as it did earlier are much
> appreciated.

Some other things that might help in either tracing or fixing the problem:

You didn't mention whether you used pulse-audio, tho I'd guess if you 
did, you'd have mentioned it instead of alsa.  Jack-audio might be 
another factor.  I have basically no experience with either of those, as 
I'm highly suspect of pulse-audio (more complication of an already 
complicated system for no good reason, IMO) and don't have the specific 
real-time-audio needs that jack-audio is designed to address, so if 
you're using either of those, you're in territory I really can't address 
at all.  (You're a gentooer as I am, and I think we both appreciate the 
additional control gentoo gives us over such options as compared to some 
distros. =:^)

You might try running alsa-mixer in a text terminal (either window or 
VT), in both the older kernel and the new 3.2.1 kernel, and note any 
changes to control order, labeling, etc, that you might see.  kmix is a 
high-level-GUI that sometimes hides details that you may need to note, 
while alsamixer's part of alsa-utils itself, and should therefore more 
faithfully represent the exposed alsa device state.

You mention that 3.1.5 worked and 3.2.1 doesn't.  You might try the 
latest 3.1.9 (LWN's coverage of the stable releases says yesterday/
thursday for it, so it's quite new) to see if it's in the latest 3.1 
series stable, and 3.2.0 to see if it's in the initial 3.2 release, to 
nail down whether it's a stable-update issue or only appeared in the
3.1 -> 3.2 upgrade.  Of course, I doubt gentoo-sources patches have 
anything to do with this, but I run vanilla mainline Linus kernels here, 
and that's what I'd suggest you verify with, just to be sure.

You can of course check 3.2-rcX releases as well, at least rc1, to see 
whether the change appeared in the commit window or between that and 
final 3.2 release.

Also, you don't mention which audio hardware/alsa-driver you run.

By nailing down the hardware/driver and whether it occurred between 
stable series releases or in the 3.1 > 3.2 upgrade only, and within that, 
whether it appeared in the initial commit window or afterward, as I run a 
live-git kernel here and have the git tree right at hand, I can then 
check commits and see just how many were applied to alsa for that driver 
during the window in question.   Once it's narrowed down to a few 
commits, I can see what they actually are and why they were applied, and 
can very possibly either give you a workaround or at least trace the bug 
down for filing or whatever.

As an example, the hda-intel alsa driver alsa driver used for my netbook 
is incredibly common as an integrated sound device, but there's a huge 
number of variants in the way it's actually hooked-up on-board depending 
on manufacturer and board model, and newer kernels constantly add 
additional tweaks for one or another board variants that might 
occasionally not actually apply to all the models the tweak tries to 
cover.  A fix for something like this is as simple as adding the 
appropriate kernel or module loading command line switch, to tell the 
driver what variant to use, instead of the default one all those tweaks 
are constantly trying to get right for all the hundreds of models out 
there that use the same base driver.

The alsamixer comparison is toward the same end, as often those variants 
and associated tweaks simply change which mixer channel controls which 
device and how they're labeled.  Getting master and headphone out 
reversed is one of the most common issues and very possibly exactly what 
happened here, but precisely because it is so common, the fix is also 
very easy (at least for a gentooer), simply tell the kernel or module the 
variant it's supposed to use manually, so it doesn't have to guess.

Meanwhile, there's yet another element in play as well.  What phonon-
backend(s) do you have installed and which one is active?  In gentoo, the 
backend packages are media-libs/phonon-*, where * is either gstreamer 
(the current kde and gentoo/kde default), vlc (the one I'm running), or 
xine (the most usable one with early kde4, but now deprecated and on 
gentoo actually masked).

The in-kde phonon backend selector is in kde settings, hardware 
multimedia, phonon, on the backend tab.  There's a reason phonon-xine is 
now deprecated/masked as it proved troublesome for many people.  phonon-
vlc has been far better for me, while phonon-gstreamer works better for 
some.

FWIW I haven't had gstreamer on my system since I had problems with it 
years ago.  I'm sure it's much better now, but that's why I chose the vlc 
backend here, as both required merging a bunch of dependencies and I 
decided I'd rather try vlc and see what all the good reviews I'd read 
were about, than the gstreamer I'd had such problems with years ago.

So you can try switching phonon-backends too, altho given that it was a 
kernel upgrade that triggered the problem, and the known symptoms fit the 
common headphone/master reversed scenario so well, I'd suggest that's the 
likely most direct solution, tho a different backend may possibly work 
too.

While we're there, in device preferences (first tab in phonon settings), 
you may have several devices shown that you can rerank if desired.  I 
occasionally have troubles with one of them, with a phonon notification 
popup telling me that it's dropping to the next one on the list.  That 
wouldn't appear to be your problem ATM, but if you happen to notice 
phonon complaints at some point, fiddling with the order there, testing 
each device individually and placing any that don't work or don't work 
reliably toward the bottom, may help.

Finally, one last note.  I don't actually have kmix even installed on my 
main machine (the one I keep constantly updated), as it's attached via
S/PDIF digital out to my 5:1 stereo, and other than a single analog/
digital selector-toggle and a second spdif related control that I haven't 
quite figured out but which seems to simply work in one of four positions 
and in none of the others, none of the mixer controls do much if 
anything.  So there's not a whole lot of volume control to be done at the 
hardware level on my main machine, which works out just fine since I use 
the 5:1 system as master volume, and set individual app volume in the 
individual apps.

Meanwhile, I do have kmix installed on my netbook, where it's actually 
useful, but I don't update that frequently at all (last time it was 8 
months, this time it's already past that and it might reach a year, I 
think it's still running early kde 4.6 with a kernel of similar vintage, 
and I've been running the 4.8 betas and rcs and run a live-git kernel on 
my main machine), so while I'm familiar with kmix in general, I don't 
really have a clue what it has done in 4.7 or 4.8, if it has changed at 
all.

I think there was one more suggestion I was going to mention but I can't 
remember it now, so I guess I'll post this, and if the others don't work 
and it was important, I'll probably remember it later...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman




More information about the kde-linux mailing list