At Mon, 29 Dec 2008 19:45:25 +0100, Nigel Henry wrote:
UPDATE: Salvatore has found a workaround, so that both codecs are detected correctly. Any help from alsa developers for a permanent fix would be appreciated. See workaround at bottom of post.
(snip)
<Quoting Salvatore> Saturday 16:05:58
Ok, I finally found a workaround. According to the thread starting at http://thread.gmane.org/gmane.linux.alsa.devel/58849 I grabbed the latest source code alsa-driver-1.0.18a.17.g27a32.139.g6e583/ compiled with --with-debug=verbose and got the message Dec 27 15:13:06 localhost kernel: ALSA /mnt/travel/ALSA/alsa-driver-1.0.18a.17.g27a32.139.g6e583/pci/hda/../../alsa-kernel/pci/hda/hda_intel.c:779: codec_mask = 0x2
I then figure out that the sound device was at codec#0 when it worked, therefore I changed snd_hda_intel.c by forcing codec_mask if (!chip->codec_mask) { chip->codec_mask = azx_readw(chip, STATESTS); chip->codec_mask=0x03; snd_printdd("codec_mask = 0x%x\n", chip->codec_mask); }
And now the sound works correctly. Of course this opens the question of why azx_readw does not return a correct mask;
Well, this implies a BIOS bug. This value is set by BIOS to indicate which codec slot is available.
maybe the developers will be interested and/or will suggest a fix that is a little more elegant/widely applicable? And why did the base code work just once, for no clear reason ? (I did not have debug=verbose at that time, so I don't have detailed messages in the system log).
Not sure about this as I didn't track this bug. When did it work once? Is the device enabled by BIOS properly?
thanks,
Takashi