For the second time I sent a mail to [email protected] 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.
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
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
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