Bug 24731 - i810_audio timing issues
Summary: i810_audio timing issues
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-01-23 19:36 UTC by Rogelio Noriega
Modified: 2005-10-31 22:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-01 10:12:05 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Test patch to autotune the clock rate of i810 audio codecs (5.33 KB, patch)
2001-03-01 10:11 UTC, Doug Ledford
no flags Details | Diff

Description Rogelio Noriega 2001-01-23 19:36:27 UTC
Dell WS220 with i815 chipset (Intel Corp I82801AA AC 97 Audio)

When attemping to play phone.wav from a command line file plays very fast, 
message returned was

sox: unable to set audio speed to 44100 (set to 48000).
Works fine using esdplay.

if I try and play yahoo.wav again it very fast and message returned was

sox: Sound card appears to only support singled word samples. Overriding 

sox: Couldn't set to mono.

sox: Uable to set audio speed to 11025 (set to 48000)

One other thing mixer settings were set low, I had to manually adjust 
settings before sounds could be heard. Works fine using esdplay.

Comment 1 Arjan van de Ven 2001-01-24 09:52:54 UTC
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)

Comment 2 Dan Taylor 2001-01-30 20:19:55 UTC
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.

Comment 3 Rogelio Noriega 2001-02-07 15:58:04 UTC
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.

Comment 4 Dan Taylor 2001-02-21 18:46:17 UTC
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.

Comment 5 Arjan van de Ven 2001-02-22 09:44:59 UTC
"play" might not know 48Khz. File a separate bug against that please.
The "PWS220 and the 4100" issue still needs investigating
ftso_dell=2 ?

Comment 6 Dan Taylor 2001-02-22 15:23:48 UTC
Updating priority of this bug.

Comment 7 Doug Ledford 2001-03-01 10:08:28 UTC
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.

Comment 8 Doug Ledford 2001-03-01 10:11:56 UTC
Created attachment 11423 [details]
Test patch to autotune the clock rate of i810 audio codecs

Comment 9 Doug Ledford 2001-03-02 03:51:10 UTC
I'm resolving this as rawhide.  Reopen if it isn't solved by the latest kernel.

Note You need to log in before you can comment on or make changes to this bug.