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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media Development]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Xfree86]     [Fedora Women]     [Linux USB]

  Powered by Linux