Subject: Re: [linux-audio-dev] Realtime
From: yodaiken_AT_fsmlabs.com
Date: Thu Jun 29 2000 - 23:09:56 EEST
On Wed, Jun 28, 2000 at 12:15:23AM -0400, Paul Barton-Davis wrote:
> 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.
Cool.
>
> 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:
The buffering is not configurable?
>
> 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).
600 usecs is a very long time for PIII700 or an Alpha.
It should be more than 600,000 instructions.
There are no interesting things to do in such times?
Is it interesting to do "live" effects?
Music in -> do something ->Music out
|->log
> 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.
The current learning curve is too high -- hence my note.
-- --------------------------------------------------------- Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico.
This archive was generated by hypermail 2b28 : Thu Jun 29 2000 - 23:38:04 EEST