i810 audio doesn't work with 2.4.9
Hi!
Quoted 11 lines · Doug Ledford
So it seems that update of
i810_audio.cbetween 2.4.6-ac1 and ac2 breaks it (at least for me).Quoted 3 lines
But I think it still eating too much time (about 2-3% on PIII 700) when I'm not doing anything with sound but no more up to 90% as with unmodified version from 2.4.9 (maybe it's a problem of artsd , I don't know)
Yes, it's a problem of artsd. Someone decided (presumably to avoid the occasional pop/click from the startup or shutdown of the sound device) to make artsd transmit silence over the sound card when no sounds currently need played. From my perspective, I will *NEVER* use artsd as long as it does this. [... more rant ...]
More or less recent versions of artsd either autosuspend (close the sound device) either after hard-coded 60 seconds of inactivity, or have a command line option
-s <seconds> auto-suspend time in seconds
which should adress this issue.
Quoted 3 lines
Furthermore, I find
their use of the sound API to be suboptimal, especially when they are going to transmit silence all the time. [...]
Well, artsd does non-blocking sound I/O combined with select() which tells it when to wake up and write (read) something. It usually works quite nice if the driver is implemented correctly, that is, if it wakes up artsd if there is a suitable amount of data to read (write) - usually a fragment is a good choice for the driver. The use of the API has the advantage that it
- doesn't require threads (synchronization, context switches)
- works well with very low latencies
- never blocks the server (i.e. the server can always accept requests from the net)
Common problems with some drivers appear to be:
* GETOSPACE/GETISPACE lies about the size that can be read/written (non-fatal, as long as there is at least some truth in there)
* select() does wake up too early (i.e. if either nothing at all or just a small amount can be read/written) - thats fatal and leads to the 90% CPU scenarios
(I am not subscribed to linux-kernel, so in doubt CC me).
Cu... Stefan
Signature · 2 lines
-* Stefan Westerfeld, [email protected] (PGP!), Hamburg/Germany KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
Quoted 9 lines · Stefan Westerfeld
Hi!Quoted 5 lines · Doug Ledford
Yes, it's a problem of artsd. Someone decided (presumably to avoid
the occasional pop/click from the startup or shutdown of the sound
device) to make artsd transmit silence over the sound card when no
sounds currently need played. From my perspective, I will *NEVER* use artsd as long as it does this. [... more rant ...]
Quoted 7 lines
More or less recent versions of artsd either autosuspend (close the sound device) either after hard-coded 60 seconds of inactivity, or have a command line option
-s <seconds> auto-suspend time in seconds
which should adress this issue.
That's a vast improvement. Glad to hear it.
Quoted 9 lines
Quoted 2 lines
Furthermore, I find their use of the sound API to be suboptimal, especially when they are going to transmit silence all the time. [...]
Well, artsd does non-blocking sound I/O combined with
select()which
tells it when to wake up and write (read) something. It usually works
quite nice if the driver is implemented correctly, that is, if it
wakes up artsd if there is a suitable amount of data to read (write) - usually a fragment is a good choice for the driver. The use of the API has the advantage that it
Quoted 4 lines
- doesn't require threads (synchronization, context switches)
- works well with very low latencies
- never blocks the server (i.e. the server can always accept requests from the net)
This is all fine.
Quoted 4 lines
Common problems with some drivers appear to be:
* GETOSPACE/GETISPACE lies about the size that can be read/written (non-fatal, as long as there is at least some truth in there)
This is my complaint. It's redundant and useless to do non blocking I/O *and* also waste time on GETOSPACE/GETISPACE syscalls. Unless you are wanting to flirt with the very edge of having the sound buffer emptied so that you are only microseconds ahead of the dma engine and any new sound can be instantaneously transmitted to your speakers, just write to the damn file until you get a write that returns with a short write value (aka, not all data was written to the device), then sleep and wait for select to wake you up. GETOSPACE/GETISPACE are there so you know how much data you can write, which keeps you from ever blocking. Non blocking I/O is so you don't have to worry about how much space is available to write to. Yes, you can use them together if you want, but it makes almost no sense and is a waste of CPU cycles.
Quoted 3 lines
*
select()does wake up too early (i.e. if either nothing at all or just a small amount can be read/written) - thats fatal and leads to the 90% CPU scenarios
The difference between GETOSPACE and write can also cause the same thing (something I just fixed in the i810 driver I'm working on here). However, if the sound driver is waking you up from a select call when it isn't suppossed to, that's a driver bug and not something that you should have to work around. The workaround just perpetuates the broken drivers.
Quoted 4 lines
(I am not subscribed to linux-kernel, so in doubt CC me).
Cu... Stefan
Signature · 3 lines
Doug Ledford <[email protected]> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems