Subject: Re: [linux-audio-dev] Realtime
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Jun 28 2000 - 07:15:23 EEST
>> i think, however, that all of this is moot. For almost all of us, the
>> performance offered by Ingo's patches to 2.2.{10,11,12,13,14,15} is
>> more than adequate. Using RTLinux involves, at the absolute minimum,
>> some real work, a definite learning experience, and possibly a
>> redesign of already operational applications. To gain what ? Better
>> performance than we actually need. victor, its a tough sell ;)
>
>Someone told me that about "C" in 1980. How's that for a stunningly
>irrelevant response?
>I think that the motivations of performance and intellectual
>curiosity are strong.
take a look at the hardware.
44.1kHz -> 1 sample = 22usec
48kHz -> 1 sample = 20usec
96kHz -> 1 sample = 10usec
192kHz -> 1 sample = 5usec
so RTLinux would could our performance down to roughly the same level
as the converters.
alas, its nots so simple. there are always buffers on the audio
interface which accumulate sample data in both directions. plus, there
is the PCI bus burst transfer size (64 bytes). so, lets assume a
minimum transfer size of 64 bytes:
16 32 bit samples @ 48kHz: 320usec
32 16 bit samples @ 48kHz: 640usec
so, clearly, RTLinux would get us down to the h/w limits of today's
audio interfaces.
this is an attractive goal in some senses, except for the fact that as
Benno has pointed out, doing a single pass through our audio algorithm
is probably going to cost *at least* the same time *just for the
overhead* (i.e forget any actual computation).
so, its back to the age-old (well, as old as the Music N language
family) tradeoff between a "blocksize" (number of samples processed
per iteration) that favors rapid response and one that favors high
efficiency.
realistically, people have found with programs like Csound that the
best compromise value is probably on the order of a 100 to 1000
samples depending on the application. in some cases, a sample size of
1 is necessary (e.g. to properly implement some kinds of
filters/delays).
Lets pick 256 as a nice power of 2 number:
256 samples @48kHz: 5ms
Presto: we can do 2.5ms with Ingo's code. So we're in the clear here
for almost all applications.
There are a few cases where the ability to do "better" than the h/w
can is a win. But these are very rare - I don't know of any current
pro-audio gear that even attempts such a thing. Single-sample transfer
is common for thru routing, but its rare when doing signal processing.
My take-home point; RTLinux is a fabulous piece of work. But it lets
us do better than we need to at the cost of a bunch of driver porting,
app redesign, and some learning, contrasting with the low latency
patches which involve no change in app design (i.e code runs on
dog-slow latency systems too, albeit poorly), no "porting" of drivers
to a new "platform", and the chance to carry on as usual. ah, what a
pathetic specimen i am.
--p
This archive was generated by hypermail 2b28 : Wed Jun 28 2000 - 07:44:46 EEST