intel8x0-snd module fails to correctly detect clock when compiled in kernel

intel8x0-snd module fails to correctly detect clock when compiled in kernel

[Martin van Es]

For the second time I sent a mail to perex@suse.cz a couple of days ago 
without any reply so far, so I thought I'd let the kernel mailinglist reader 
know of my findings as well.

Maybe anybody else can do something with the knowledge that the intel8x0-snd 
module fails to detect the 'clock' correctly if built into the kernel, as a 
module this works fine. If not for anything else, I hope this mail gets 
archived and the solution is available for anybody else having the same 
problem.


Below is the verbatim mail as I sent it to Jaroslav:

Yesterday I compiled the fresh 2.6.18 kernel and to my big surprise I 
discovered my sound was a bit off speed (too slow, like 48000 content was 
played at 44100 or so). Hence my immediate search for clock problems.

A bit of searching revealed that the ac97#0-0 file (in /proc/asound/card0 dir) 
contains 2 lines referring to 441~ and 48~.
In 2.6.18 these lines 

PCM front DAC    : 48000Hz
PCM ADC          : 48000Hz

Both lines alternate between 44100 and 48000 between reboots (and I can't find 
what it depends on).

dmesg outputs the following 2 lines concerning audio clock:
intel8x0_measure_ac97_clock: measured 50992 usecs
intel8x0: clocking to 43920

The 'clocking to' line is not always the same, but never 48000.

Don't ask me why, but at last I tried to build the intel8x0-snd driver as a 
module and surprisingly that always results in correct funcionality. The 2 
dmesg lines now read:
intel8x0_measure_ac97_clock: measured 50463 usecs
intel8x0: clocking to 48000

The clocking line is always 48000, just like it used to be in 2.6.17.

I tried to use ac97_clock=48000 as kernel boot parameter, but the doesn't 
help (for the in-kernel version of the module).

ALSA version in 2.6.18 is:
Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 
13:55:50 2006 UTC).

My alsa intel8x0 device string is:
ALSA device list:
#0: Intel 82801DB-ICH4 with ALC202 at 0xe0100c00, irq 10


For the time being, my problem is solved by compiling the driver as module.
In the future however I'd appreciate building my kernel monolithic again.


Hope the information and bugreport is of any use to improve the intel8x0-snd 
module in future kernels.

Regards,
Martin van Es
-- 
If 'but' was of any use, it would be a logical operator.

Re: [Alsa-devel] intel8x0-snd module fails to correctly detect clock when compiled in kernel

[Clemens Ladisch]

Martin van Es wrote:
> Yesterday I compiled the fresh 2.6.18 kernel and to my big surprise
> I discovered my sound was a bit off speed (too slow, like 48000
> content was played at 44100 or so). Hence my immediate search for
> clock problems.
>
> A bit of searching revealed that the ac97#0-0 file (in
> /proc/asound/card0 dir) contains 2 lines referring to 441~ and 48~.
> In 2.6.18 these lines
>
> PCM front DAC    : 48000Hz
> PCM ADC          : 48000Hz
>
> Both lines alternate between 44100 and 48000 between reboots (and I
> can't find what it depends on).

These are the playback and capture sample rates used by the hardware.
The rate is that of the file last played (or currently being played).

> dmesg outputs the following 2 lines concerning audio clock:
> intel8x0_measure_ac97_clock: measured 50992 usecs
> intel8x0: clocking to 43920
>
> The 'clocking to' line is not always the same, but never 48000.

The AC'97 specification says that the AC'97 bus runs at 48 kHz.
However, there is some hardware that doesn't use this frequency, so
the driver tries to measure the actual rate.

> Don't ask me why, but at last I tried to build the intel8x0-snd
> driver as a module and surprisingly that always results in correct
> funcionality. The 2 dmesg lines now read:
> intel8x0_measure_ac97_clock: measured 50463 usecs
> intel8x0: clocking to 48000

It seems that, when compiled in the kernel, some other code runs at
the same time as the clock measuring code and interferes with it,
probably by disabling interrupts for too long.

> I tried to use ac97_clock=48000 as kernel boot parameter, but the
> doesn't help (for the in-kernel version of the module).

This option is intended to specify a value different from the
default.  Try 47999.  ;-)


HTH
Clemens

Re: [Alsa-devel] intel8x0-snd module fails to correctly detect clock when compiled in kernel

[Takashi Iwai]

At Tue, 26 Sep 2006 16:25:23 +0200,
Clemens Ladisch wrote:
> 
> > I tried to use ac97_clock=48000 as kernel boot parameter, but the
> > doesn't help (for the in-kernel version of the module).
> 
> This option is intended to specify a value different from the
> default.  Try 47999.  ;-)

48000 is indeed taken as 48000 Hz in the recent version.  It's 0
meaning the default value for auto-measurement.

For passing a value for driver-specific boot options, you have to add 
"DRIVER." prefix to the option name, such as
	snd_intel8x0.ac97_clock=48000


Takashi

Re: [Alsa-devel] intel8x0-snd module fails to correctly detect clock when compiled in kernel

[Takashi Iwai]

At Tue, 26 Sep 2006 16:25:23 +0200,
Clemens Ladisch wrote:
> 
> Martin van Es wrote:
> > Yesterday I compiled the fresh 2.6.18 kernel and to my big surprise
> > I discovered my sound was a bit off speed (too slow, like 48000
> > content was played at 44100 or so). Hence my immediate search for
> > clock problems.
> >
> > A bit of searching revealed that the ac97#0-0 file (in
> > /proc/asound/card0 dir) contains 2 lines referring to 441~ and 48~.
> > In 2.6.18 these lines
> >
> > PCM front DAC    : 48000Hz
> > PCM ADC          : 48000Hz
> >
> > Both lines alternate between 44100 and 48000 between reboots (and I
> > can't find what it depends on).
> 
> These are the playback and capture sample rates used by the hardware.
> The rate is that of the file last played (or currently being played).
> 
> > dmesg outputs the following 2 lines concerning audio clock:
> > intel8x0_measure_ac97_clock: measured 50992 usecs
> > intel8x0: clocking to 43920
> >
> > The 'clocking to' line is not always the same, but never 48000.
> 
> The AC'97 specification says that the AC'97 bus runs at 48 kHz.
> However, there is some hardware that doesn't use this frequency, so
> the driver tries to measure the actual rate.
> 
> > Don't ask me why, but at last I tried to build the intel8x0-snd
> > driver as a module and surprisingly that always results in correct
> > funcionality. The 2 dmesg lines now read:
> > intel8x0_measure_ac97_clock: measured 50463 usecs
> > intel8x0: clocking to 48000
> 
> It seems that, when compiled in the kernel, some other code runs at
> the same time as the clock measuring code and interferes with it,
> probably by disabling interrupts for too long.

I rechecked the driver code and found that it should be irrelevant
with the spinlock period.

The driver checks the start time via do_gettimeofday(), then sleeps
50ms via msleep(50), wakes up, checks the current DMA position by
reading a register and then marks the end time vai do_gettimeofday()
again.  The clock speed is computed from the period time between two
time marks and from the DMA position.
Both the DMA-position-reading and do_gettimeofday call are protected
in the same spinlock, so there shouldn't be so much delay between
them.  And even if there were, the calculate rate would be bigger, not
smaller.

So, the problem is either:
- DMA position is reported wrongly, or
- do_gettimeofday() returns inaccurate time

A puzzling thing is that the period time measured is 50992 usecs, so
it looks correct.  Assume that the DMA register is correct, another
theory is that the whole time on the system goes faster at this stage,
and both jiffies and gettimeofday() are inaccurate.

Anyway, I feel that we can skip this check for ICH4 and later
machines.  I don't know of any devices with non-48k clock on recent
boards, and we can save a bit boot time by skipping this measurement.


Takashi