Patch for proper hardware detection by snd-hda-intel driver

["Marvin Stodolsky" <marvin.stodolsky@xxxxxxxxx>]

Below is a fix for those with High Definition Audio cards hosting
softmodems, which have been failing to in proper detection of the
modem hardware.  Thanks to slmodem maintainer Sasha K for spotting the
problem and ALSA  Takashi Iwai  for immediately writing the patch
below.   It would be too have a few effected users try  the patch and
report back.

I'll provide procedure details later.

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);