[H-GEN] Intel 810 Audio problems

[David Makepeace]

[ Humbug *General* list - semi-serious discussions about Humbug and     ]
[ Unix-related topics. Posts from non-subscribed addresses will vanish. ]

On Wed, 3 Jul 2002, Brad Douglas wrote:

> Hi All,
>
> I've been bashing my head against a wall trying to get my integrated intel sound card to work under redhat 7.2.
>
<SNIP>
> Here's the contents of my /var/log/message file after loading the module:
> Jul  3 08:38:50 tfsec kernel: Intel 810 + AC97 Audio, version 0.05, 17:36:29 Sep  6 2001
> Jul  3 08:38:50 tfsec kernel: PCI: Found IRQ 9 for device 00:1f.5
> Jul  3 08:38:50 tfsec kernel: PCI: Sharing IRQ 9 with 00:1f.3
> Jul  3 08:38:50 tfsec kernel: PCI: Setting latency timer of device 00:1f.5 to 64
> Jul  3 08:38:50 tfsec kernel: i810: Intel ICH2 found at IO 0xe000 and 0xdc00, IRQ 9
> Jul  3 08:38:50 tfsec kernel: ac97_codec: AC97 Audio codec, id: 0x4144:0x5360 (Analog Devices AD1885)
> Jul  3 08:38:50 tfsec kernel: i810_audio: setting clocking to 7031
<SNIP>
>
> If anyone out there has some words of wisdom I'd be grateful.
>
> Regards
> Brad

Hi Brad,

AC97 is a multimedia serial bus.  Many Intel motherboard chipsets have an
AC97 controller built in but they don't include the codec.  There are many
different manufacturers of codecs which differ in features such as number
of channels and number of supported sample rates [1].  It is up to the
motherboard manufacturer to select a codec.

Recent versions of the i810_audio driver try to guess the base sample rate
of the attached codec - often unsuccessfully.  It does this by playing a
small buffer full of silence and seeing how many samples are played in a
fixed period of time.  Other devices interrupting at this time can cause
erratic results.

If the result is close enough to 48000 it assumes the base sample rate is
exactly 48000 (as most implementations clock the codec at that rate [2])
and doesn't even bother printing the "i810_audio: setting clocking to ..."
message.

I have a notebook with an Intel 440MX chipset and use a PC at work with an
Intel i815 chipset.  Both use the i810_audio driver but use different
codecs.  The notebook uses a SigmaTel STAC9744/45 and the PC uses an Analog
Devices AD1885 (just like your PCs).  I have found that the PC at work is
much less reliable at detecting the clock rate.

I found some success with removing and reinserting the module while the
machine was not doing any I/O until the "setting clocking to ..." message
went away.

  # modprobe -r i810_audio
  # modprobe i810_audio
  # dmesg

Theoretically you should also be able to do:

  # modprobe i810_audio clocking=48000

or, perhaps in your case

  # modprobe i810_audio clocking=24000

... but the driver ends up overwriting the clocking variable with the
calculated value anyway.  (At least it does in version 0.04, I notice you
are using 0.05)

If you don't mind building your own kernel, you could try removing the
following lines from the driver source, i810_audio.c, (assuming it is
still like this in 0.05) and rebuilding:

    if (i > 48500 || i < 47500) {
      clocking = clocking * clocking / i;
      printk("i810_audio: setting clocking to %d\n", clocking);
    }

If that doesn't work then it's probably a hardware problem.  :-)

Alternatively, as has already been suggested, you could try the ALSA
driver instead.

Cheers,
David.

[1]  You should know that the sort of ICH style AC97 hardware supported by
     i810_audio will only play 16 bit per channel stereo samples and only
     at a small number of supported sample rates.  Some players will
     abort with an error if /dev/dsp refuses to allow a requested sample
     format or sample rate.

[2]  I am a little puzzled that your working machine reports a value of
     24000 for the clock rate.



--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.  See http://www.humbug.org.au/