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

[Takashi Iwai <tiwai@suse.de>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/