The patch described below is in principle to be applied in the
alsa-drivers-Version/
folder by
cd alsa-kernel
patch -p1 < /path_to/hda.patch
but it hasn't worked as yet and we are awaiting a further fix from ALSA.
In the meantime a work around might be to:
1) drop back to the ALSA version 1.0.13 alsa-driver and alsa-lib sources
2) compile snd-hda-intel and its dependent drivers
3) install them, reboot and test.
To do the compile, download from http://www.alsa-project.org/ the
version 1.0.13 lib and driver packages. For instructions see:
http://linmodems.technion.ac.il/archive-seventh/msg00282.html
MarvS
---------- Forwarded message ----------
From: Takashi Iwai <tiwai@xxxxxxx>
Date: Apr 10, 2007 5:13 AM
Subject: Re: [marvin.stodolsky@xxxxxxxxx: Re: Eberhard, Germany,
Fedora Core release 6 (Zod), kernel 2.6.20-1.2925.fc6]
To: Sasha Khapyorsky <sashakh@xxxxxxxxx>
Cc: Marvin Stodolsky <marvin.stodolsky@xxxxxxxxx>
At Tue, 10 Apr 2007 02:00:26 +0300,
Sasha Khapyorsky wrote:
Hi Takashi,
How are you those days?
Thanks, fine -- except for growing amount of bugs regarding hda-intel
;)
Recently we got couple reports about broken slmodem with HDA modems.
I also found that 9600 sample rate was removed from supported by
hda_codec list. What was the reason for this change? Is there another
way to solve this problem without removing 9600? Unfortunately slmodem
knows to work 9600 only and we don't have the source code in order to
improve this. Thanks.
It's a patch:
================================================================
# HG changeset patch
# User tiwai
# Date 1162912140 -3600
# Node ID 2ad24f7f3313b2b59aace15348e19b1971e93b12
# Parent b854fbfd238f18cbcc4b4030a40aac8815735e57
hda-codec - Fix detection of supported sample rates
Don't include 9.6kHz in the list of supported sample rates.
Since this rate isn't indicated in AC_PAR_PCM parameter,
the driver might guess wrongly as if it's available.
================================================================
IIRC, it was due to a possible problem that some codecs wrongly report
384kHz bit that points 96kHz in hda_codec.c. I overlooked that si3043
supports 96kHz.
The patch below should fix the problem. Please give it a try.
Takashi
diff -r 42321871a7dc pci/hda/hda_codec.c
--- a/pci/hda/hda_codec.c Thu Apr 05 17:08:57 2007 +0200
+++ b/pci/hda/hda_codec.c Tue Apr 10 11:08:35 2007 +0200
@@ -1368,6 +1368,11 @@ static struct hda_rate_tbl rate_bits[] =
{ 96000, SNDRV_PCM_RATE_96000, 0x0800 }, /* 2 x 48 */
{ 176400, SNDRV_PCM_RATE_176400, 0x5800 },/* 4 x 44 */
{ 192000, SNDRV_PCM_RATE_192000, 0x1800 }, /* 4 x 48 */
+#define AC_PAR_PCM_RATE_BITS 11
+ /* up to bits 10, 384kHZ isn't supported properly */
+
+ /* not autodetected value */
+ { 9600, SNDRV_PCM_RATE_KNOT, 0x0400 }, /* 1/5 x 48 */
{ 0 } /* terminator */
};
@@ -1461,7 +1466,7 @@ int snd_hda_query_supported_pcm(struct h
if (ratesp) {
u32 rates = 0;
- for (i = 0; rate_bits[i].hz; i++) {
+ for (i = 0; i < AC_PAR_PCM_RATE_BITS; i++) {
if (val & (1 << i))
rates |= rate_bits[i].alsa_bits;
}
@@ -1555,13 +1560,13 @@ int snd_hda_is_supported_format(struct h
}
rate = format & 0xff00;
- for (i = 0; rate_bits[i].hz; i++)
+ for (i = 0; i < AC_PAR_PCM_RATE_BITS; i++)
if (rate_bits[i].hda_fmt == rate) {
if (val & (1 << i))
break;
return 0;
}
- if (! rate_bits[i].hz)
+ if (i >= AC_PAR_PCM_RATE_BITS)
return 0;
stream = snd_hda_param_read(codec, nid, AC_PAR_STREAM);
