Description of problem:
With kernel 220.127.116.11-35 x86_64 FC15, there is no problem when I plug a headphones' jack in : the internal speakers are muted and I can control each output correctly.
But since 2.6.40.xxx when I plug a headphones' jack in, I get sound on both internal and headphones.
There is no mean to mute speakers by volume control (PulseAudio) anymore.
Plus when I play with (un)muting in alsamixer it just mute or unmute "speakers" or "Master" or put "Speaker" level to 0dB it's really odd : volumes or mutes of some Outputs change as I play with some other outputs from the same sound card.
Booting back on 18.104.22.168-35 solves the problem.
Using Alsa mixer I could get a workaround :
- muting "speakers" output (it DOES mute the speakers)
- tuning the "speakers" volume to my needs (even if it's muted),
- unmuting "Headphones 2",
- and play a bit with those 3 controls and the Master volume and mute controls until I get no sound from speakers and sound on headphones' output.
It doesn't do that with 2.6.38 kernel.
Sound control is all messed / mixed up.
Speakers are unmutable with PulseAudio volume control panel, I must play a bit with AlsaMixer to try to get what I want (speakers muted when headphones plugged in).
I have 2 headphones outputs and internal speakers :
- one of the two headphones output used to mute internal speakers when I connected a headphones' jack,
- the other headphones output did not mute speakers when a headphones' jack was plugged in (speakers and headphones work at the same time),
- selecting the right setting in the sound properties of pulseAudio used to control this as well (mute speakers and enable output jacks),
I forgot to let some details :
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1)
The first is "internal analog audio" and the second is HDMI.
If you need further details, just ask.
Can you show the dmesg output for ALSA? There have been a few fixes in the 3.1 kernel for the realtek codec used by hda in this area. It might be worth testing the F16 Beta live image to see if the same problem still exists there.
Here is "grep -i ALSA /var/log/messages" (with 22.214.171.124-0.fc15.x86_64) :
Oct 17 19:20:16 asus17 pulseaudio: alsa-sink.c: ALSA nous a réveillé pour lire de nouvelles données à partir du périphérique, mais il n'y avait en fait rien à écrire !
Oct 17 19:20:16 asus17 pulseaudio: alsa-sink.c: Il s'agit très probablement d'un bogue dans le pilote ALSA « snd_hda_intel ». Veuillez rapporter ce problème aux développeurs d'ALSA.Nous avons été réveillés avec le jeu POLLOUT -- cependant un snd_pcm_avail() ultérieur a retourné 0 ou une autre valeur < min_avail.
and here is "dmesg | grep -i ALSA" :
[ 31.063080] ALSA sound/pci/hda/hda_intel.c:1452 Enable delay in RIRB handling
I tried Fedora 16 Beta LiveCD and the problem is exactly the same (but no "ALSA" lines in the dmesg nor in /var/log/messages).
If you need more informations, feel free to ask. :)
Translation to english :
Oct 17 19:20:16 asus17 pulseaudio: alsa-sink.c: ALSA wakoe us up to read new data from device, but in fact there was nothing to write !
Oct 17 19:20:16 asus17 pulseaudio: alsa-sink.c: it is certainly a bug in ALSA driver "snd_hda_intel". Please report this problem to Alsa devceloppment team. We have been woken up with POLLOUT -- but a following snd_pcm_avail() returned 0 or an other value < min_avail.
Did this as root :
echo "options snd_hda_intel model=auto" >> /etc/modprobe.d/snd_hda_intel
Found it in
Thanks and bye for now!