[alsa-devel] ALC268 test model not working
Hi all,
finally I got the patch applied to kernel src :) But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument.
Is this some obscure bug in the notebook hardware or some driver bug?
Marco
(note, I apply against .24-rc6 still)
At Mon, 14 Jan 2008 17:33:18 +0100, Marco Schuster wrote:
Hi all,
finally I got the patch applied to kernel src :)
Any reason you don't use simply alsa-driver tree to build the external modules? You missed many features that will be added after 2.6.24 kernel.
But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument.
0x1d is the PCBEEP. Maybe it's disabled somehow although it's listed in the datasheet. The patch below should fix.
Takashi
--- diff -r 1f9fd3d3cb12 pci/hda/patch_realtek.c --- a/pci/hda/patch_realtek.c Mon Jan 14 12:07:53 2008 +0100 +++ b/pci/hda/patch_realtek.c Mon Jan 14 17:54:43 2008 +0100 @@ -9596,7 +9596,8 @@ static struct snd_kcontrol_new alc268_te HDA_CODEC_VOLUME("MIC2 Capture Volume", 0x19, 0x0, HDA_INPUT), HDA_CODEC_VOLUME("LINE1 Capture Volume", 0x1a, 0x0, HDA_INPUT), HDA_BIND_MUTE("LINE1 Capture Switch", 0x1a, 2, HDA_OUTPUT), - HDA_CODEC_VOLUME("PCBEEP Playback Volume", 0x1d, 0x0, HDA_INPUT), + /* The below appears problematic on some hardwares */ + /*HDA_CODEC_VOLUME("PCBEEP Playback Volume", 0x1d, 0x0, HDA_INPUT),*/ HDA_CODEC_VOLUME("PCM-IN1 Capture Volume", 0x23, 0x0, HDA_OUTPUT), HDA_BIND_MUTE("PCM-IN1 Capture Switch", 0x23, 2, HDA_OUTPUT), HDA_CODEC_VOLUME("PCM-IN2 Capture Volume", 0x24, 0x0, HDA_OUTPUT),
Takashi Iwai schrieb:
At Mon, 14 Jan 2008 17:33:18 +0100, Marco Schuster wrote:
Hi all,
finally I got the patch applied to kernel src :)
Any reason you don't use simply alsa-driver tree to build the external modules? You missed many features that will be added after 2.6.24 kernel.
I use the make-kpkg debian way of building kernels, and so I always get a warning "current directory is kernel src directory" :(
But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument.
0x1d is the PCBEEP. Maybe it's disabled somehow although it's listed in the datasheet. The patch below should fix.
Strange, I don't get any sound thou' all channels are unmuted.
Marco
PS: Do you live in Germany or speak German?
Hi
[ ALC268 test model ]
But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument.
0x1d is the PCBEEP. Maybe it's disabled somehow although it's listed in the datasheet. The patch below should fix.
Perhaps it's disabled or not implemented in the chip implementation used in this particular laptop. While the "official" ALC268 documents this control and presumedly implements it, maybe others who use the ALC268 core in their own chips don't.
If the above messages are non-fatal then it may be slightly premature to disable the PCBEEP control in the test model mixer. So long as the lack of this control in certain hardware doesn't cause loss of functionality on those systems I would suggest its better if the test model keeps this control so it is available for those people whose ALC268 does in fact implement this control. At the end of the day the test model is just a diagnostic aid, so if it emits some non-fatal messages on some hardware I don't really think that's a problem.
Of course if this issue is causing things not to work then we have to re-evaluate.
Regards jonathan
At Tue, 15 Jan 2008 08:38:31 +1030 (CST), Jonathan Woithe wrote:
Hi
[ ALC268 test model ]
But it doesn't work correctly, because when running alsamixer, dmesg tells "hda_codec: num_steps = 0 for NID=0x1d", and alsamixer fails with alsamixer: function snd_mixer_load failed: Invalid argument.
0x1d is the PCBEEP. Maybe it's disabled somehow although it's listed in the datasheet. The patch below should fix.
Perhaps it's disabled or not implemented in the chip implementation used in this particular laptop. While the "official" ALC268 documents this control and presumedly implements it, maybe others who use the ALC268 core in their own chips don't.
If the above messages are non-fatal then it may be slightly premature to disable the PCBEEP control in the test model mixer. So long as the lack of this control in certain hardware doesn't cause loss of functionality on those systems I would suggest its better if the test model keeps this control so it is available for those people whose ALC268 does in fact implement this control. At the end of the day the test model is just a diagnostic aid, so if it emits some non-fatal messages on some hardware I don't really think that's a problem.
Let's disable it unless we implement a proper probe code. The pc-beep isn't that important feature after all ;)
To make it more robust, you can check the AMP capability at first before registering the mixer element. But, this would make the code a bit more complicated. So, unless any other vital controls have the same issue, let's fix in ad hoc way.
Takashi
participants (3)
-
Jonathan Woithe -
Marco Schuster -
Takashi Iwai