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

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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: [linux-pm] Power Management framework proposal
    ... set of calls that every driver writer would implement the minimum set of, ... That is not part of the fw: the fw simply expresses parent-child clock ... Powering device on/off will certainly introduce more latency, ... standard cpufreq list of frequencies; everything else is part of the ...
    (Linux-Kernel)
  • Re: [PATCH 0/5] clocksource patches
    ... abstraction to the hardware counter below. ... I can understand that you want to keep the clock driver as simple as ... I really don't understand your problem with a clocksource specific ...
    (Linux-Kernel)
  • Re: Wanted - Apple II cards
    ... A Clock card (any other than a Mountain, hopefully a PRODOS ... However, with some heavy hatchet work, it *IS* possible to "Sourceror" the driver, chop out a bunch of extraneous stuff, re-org and reassemble it with only the "read" routine, then cram it in the space ProDOS provides for the Thunderclock driver - With 4 bytes to spare, if I recall the results of my surgery for just that purpose correctly. ...
    (comp.sys.apple2.marketplace)
  • Re: MMC: Make the configuration memory resource optional
    ... With this patch such hardware can pass a single ctl ... The feature request to allow the driver to work with a single ... I think everyone wants to use the clock API to control clocks. ...
    (Linux-Kernel)
  • Re: [RFC][PATCH] PM: Introduce core framework for run-time PM of I/O devices (rev. 8)
    ... and not in a ->runtime_resumecallback. ... be cleaner to use a similar counter based interface from the driver ... The most simple level is clock stopping, ... clock and decreases the power domain usage count. ...
    (Linux-Kernel)