Stefan Westerfeld wrote:
> Hi!
>
> On Thu, Aug 23, 2001 at 08:03:00PM +0000, Doug Ledford wrote:
>>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.
That's a vast improvement. Glad to hear it.
>>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)
This is all fine.
> 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.
> * 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.
> (I am not subscribed to linux-kernel, so in doubt CC me).
>
> Cu... Stefan
>
--Doug Ledford <dledford@redhat.com> http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Aug 31 2001 - 21:00:11 EST