Subject: [linux-audio-dev] audio app timing architectures
From: est_AT_hyperreal.org
Date: pe elo 06 1999 - 08:19:31 EDT
Paul Winkler discourseth:
> est_AT_hyperreal.org wrote:
> >
> > Paul Winkler discourseth:
>
> > In addition to latency patches, I'm beginning to regard including a
> > patch that accerlerates the timer interrupt to greater than the
> > current 100hz as essential. It provides a means of escaping from
> > these monolithic applications that are clocked by the soundcard.
> >
>
> My ignorance is showing again-- what's this all about?
> What's an example of a monolithic app. clocked by the soundcard?
www.hyperreal.org/~est/oolaboola :) ..or wavplay for that matter. How
do these apps know when to sleep? They know by blocking in their
writes to the soundcard when the soundcard driver's buffers are full.
Having to do this leads to a pc-like i-must-seize-control-of-the-hardware
style of coding. That's what I mean by `monolithic' as compared to a
unix-like device-independent style.
What's a real example of the latter? Well, I'm adding quadrophonic
(actually more general multi-channel) output to oolaboola, and I want
people to be able to do it with a couple of cheap soundcards. Now,
your excellent Audio-Quality HOWTO explains, I believe, why this won't
work; but I think I can make it work. :)
I'm planning on having separate processes, one for each soundcard,
that take their input from oola and output to their soundcard doing
resampling to deal with timing descrepancies. (I've got a design in
mind for a general audio process architecture that does this sort of
thing via shared-memory and/or network connections.) But if I do that,
oola can't block on it's writes to these processes, it has to output
to them at a fixed rate of *its* choice, and it can do this by calling
nanosleep() at appropriate times.
However, currently, linux on x86 has a timer interrupt at 100 hz.
This is too coarse to allow the above strategy *and* have
low-latencies/high-responsiveness. Something more like 1024 hz timer
interrupts would be more practical. Switching to that is as easy as
changing the definition of HZ in the kernel, however, their are issues
with that. Some user-space apps that assume HZ=100 would need to be
fixed and/or rebuilt. Some of this could be handled by kernel patches
that have been floating around that would lie to these user-space
apps, but there's some disagreement about the right approach. There
may also be some issues in ther kernel itself, and there are proposed
patches for some of these.
I hope this helps explain my concerns. :)
Eric
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST