Bug 24731

Your chipset only supports 48Khz, and the consensus is that userspace and not
the kernel should do the frequency conversion. ESD and some other programs do
that correctly, sox apparently not.

If even ESD based programs don't work, you should try the "ftsodell=1" module
commandline option. (Fix The Sound On Dell)

Beta3/Fisher - Used the FTSODELL=1 option.  play runs too fast.  esdplay plays 
too slow.  Gnome gets errors with snd recorder playing waves. Sound device not 
ready.  mmap not functional.

We are seeing the same problem with the Dell Dim XPS 4100, also if a mpeg is 
played using GTV MPEG player its plays very fast in sync with the audio.

As of Wolverine release, this is still failing as follows.  This ADI 1885 chip 
is on the Dimension 4100, Optiplex GX150.  The AD1881 is on the PWS330, and the 
PWS 220.  All of them load the i810_audio driver module.  

With ftsodell=1 on the PWS330 & the GX150 you can use esdplay to play audio and 
it works ok.  'play' plays too fast.

On the PWS220 and the 4100, the audio plays too fast with 'esdplay' and 'play' 
regardless of the ftsodell option.  

Note: I am also changing the summary to more accurately reflect the subject.

"play" might not know 48Khz. File a separate bug against that please.
The "PWS220 and the 4100" issue still needs investigating
ftso_dell=2 ?

Updating priority of this bug.

OK, there are two different issues under this one bug report.

First, the issue of whenever play fails (goes too fast) but esdplay (or other
similarly smart programs) play OK.  This is a bug in play (or, more
appropriately, it's a hardware limitation combined with a software limitation to
result in poor playback since the hardware won't do anything but a 48k sample
rate and play won't resample the source to get up to a 48k play rate, you get
this bug).  This is *not* a kernel bug, and might not even be considered a bug
in play.  It is entirely possible that the answer is "Don't use play on systems
with a hardwired 48k sample rate, use something smarter instead".  So, any
system where play fails and esdplay doesn't is a non-bug and I'm dropping that
from what I'm tracking in this bug report.

Second, the issue of machines that play at the wrong speed with smart playback
programs, such as esdplay.  The ftsodell=1 option used to help with this (and
for certain machines I'm sure it still works fine).  ftsodell=2 won't do
anything, the i810_audio driver only checks if ftsodell == 1 and then sets
clocking to 41197.  Sorry Arjan, that's shot down ;-)  However, I've written
what I think is a better fix to this problem.  It renders the ftsodell option
obsolete and instead replaces it with an autotuning function that will play a
sample (well, not really, it plays all 0's so it's silent) at card detect time
to determine what the correct clocking for a chip is.  My testing here has this
working more reliably now than the clocking on the Maestro 2 driver (which I
didn't know was clocked wrong until I realized this driver was clocked wrong and
then I compared them and found the Maestro 2 is also off on my laptop).  In
fact, the autotune function was accurate enough that use xmms to play an mp3
file, and using the system clock to time the playing of the mp3, for an
arbitrarily long mp3 I could no longer detect a variance between how long xmms
said it had been playing and how long the system clock said xmms had been
playing.  I'll attach the patch to this bug report for people at Dell to test. 
This will also be going into our kernel CVS as soon as I have confirmation that
it works reasonably well.  This should solve the play speed issues.

Created attachment 11423 [details]
Test patch to autotune the clock rate of i810 audio codecs

I'm resolving this as rawhide.  Reopen if it isn't solved by the latest kernel.