Subject: Re: [linux-audio-dev] plugin format
From: David Olofson (audiality_AT_swipnet.se)
Date: ke elo 25 1999 - 19:26:22 EDT
Benjamin GOLINVAUX wrote:
>
> >From what I understand from your posts regarding Audiality, it is
> basically
> an audio (& midi ?) stream engine running under RTLinux...
Yep, audio and MIDI. (Actually, MIDI will go along with the rest of the
events used for automation. Reusable sub-systems means power,
flexibility, less code, less bugs...)
> It seems like a _very_ interesting idea, but I have some questions :
>
> 1 disk performance
>
> How does RTLinux interface with the filesystem ?
It doesn't.
> Could you imagine to
> let audiality access its own partition ( la ProTools) but, even then,
Pointless. Hard drives are "high latency" by nature...
> how do you predict the latency due to the hard disk ?
Impossible. No systems do that. It's all about buffering...
> Do the spec
> include an AV hard disk (it could be the _only_ solution) ?
Yep; non-AV drives stop reading/writing when doing thermal calibration,
which results in a bandwidth drop that would require tens of seconds of
buffering to handle at any significant load. However, AV drives are just
as "sloppy" as normal drives when it comes to access times and transfer
rates, so the same rule still applies: It's all about buffering.
Basically; keep seeks below 10% of the maximum seek frequency by always
reading big chunks of data from one file at a time. A reasonable value
is 384 kB per file for 32 tracks at 44.1 kHz, 16 bit data on a decent
5400 rpm drive. (Try this on Cakewalk, Cubase VST or whatever if you
like... That's how you actually get those programs to do anything
useful. They're still inefficient, though.)
Note: View the disk as analog tape. There are always access times... The
processing is done on the other end of the buffers, so the processing
latency, and consequently, the response time to real time user input, is
determined by the audio processing engine. For example, Benno Senoner
(hacked the latencytest program that Ingo Molnar used to analyse the
latency problems) managed to stream around 50 44.1 kHz mono tracks from
his 5400 rpm drive while mixing them only 4.3 ms before playback... And
that's rock solid - no drop-outs ever.
> 2 protected memory
>
> The main question I have regarding this platform is : how do you debug
> it ? I understand rtlinux code can screw the machine...
Correct.
> Do you plan to
> provide protected memory mechanism ?
Yes, but that's not an easy hack. Someone did it, but it was never
released. Victor Yodaiken suggested a solution for scheduling into user
space from RTL, but Linus was more than unhappy with all those context
checks in every user space -> kernel entrance... I have some ideas, but
I have to study the kernel code and the x86 architecture a bit more
before I can say exactly *how* complicated it is, but obviously, it's
far from trivial. (Unless those who tried missed something...)
> One good thing would be to let people test and debug their plugins
> using SCHED_FIFO... Provided enough similarities between the two
> programming models...
That's _exactly_ what I'll do. Actually, the full blown engine will be
possible to compile as a user space daemon/server as well as the RTLinux
kernel version, so there's no difference whatsoever, appart from
latency.
> 3 drivers
>
> Your driver abstraction layer seems very cool... It's just that there
> is no high-quality audio card for Linux yet, am I wrong ?
There are, but those I know anything about have only binary OSS
drivers... I *can* use those drivers, however, as long as they support
mmap(). It's possible to run the engine as an RTLinux periodic task,
synchronized with the interrupts from the sound card. (That is, the
standard driver runs the card "freewheel" in mmap() mode, while the
engine hooks in on the IRQ to sync it's [higher frequency] periodic
scheduler. The engine transfers data to/from the card through the
mmap()ed window, so it never has to leave RT context.)
> I'm actually trying to develop a small dsp test bed using BeOS (I'm not
> developing for Linux yet) and I think the MediaKit programming model is
> very clean.
>
> However, this is not hard-real time, which I agree is _indispensable_
> for audio production (yes, indispensable).... But will the constraints
> of RTLinux be viable for the developers ?
What constraints? The only problem that a _serious_ hard real time
programmer would react on is the lack of protected memory, but this can
be fixed. And the fix won't have affect the plug-in code; not even
existing binaries, if the API is planned correctly from the start.
Regarding system calls: If you're a hard real time programmer, you know
that's out of the question unless the system is a pure RTOS. And even
with QNX and similar systems, obviously, all resources can't be hard
real time capable. The same rules apply to RTL - the only difference is
that RTL doesn't (yet) implement a full wrapper for the non-real time
system, so you can't do the silly mistake of breaking real time
performance by calling non-real time system calls.
> Another question : since BeOS claims to be the MediaOS (which I agree
> being given their nice architecture), is Linux _as good as BeOS_
> regarding audio _right now_ (I mean, even without audiality) ?
>
> I read about the linux 5ms latency using a new kernel patch, which is
> slightly more than Be engineers claim to have achieved using an Event
> Layla...
Well, the Linux latency figures holds true for normal consumer sound
cards with standard drivers, and it's completely rock solid regardless
of system stress. This is with 80% of the CPU power being used for
signal processing in that 4.3 ms latency thread...
Layla is pretty good pro card (I happen to own one, BTW...) _designed_
for this kind of things. And what kind of driver is that Layla/BeOS
driver? Standard BeOS audio driver? And what about using the CPU from
that real time thread, and what about reliability? I won't take Be
Inc.'s claim too seriously until I get some _hard facts_ about what
they're actually doing.
There are many ways to cheat... We don't. :-)
> Does it mean that, under some circumstances, one can process and audio
> stream 'live' under Linux with 5ms latency WITHOUT GLITCHES ?
Yep. (However, I think you'll either get just above 5 ms, or have to use
less than 80% CPU for processing if you're streaming from audio in to
audio out.) Benno has stressed his machine for hours and hours without
ever getting a drop-out, and the only "problem" we have left is the 2.9
ms jitter peak that limits latency to those 4.3 ms.
> Does the non-preemptive kernel block the audio processing sometimes ?
Nope. :-)
> Network ?
Nope. :-)
> disk ?
Nope. :-)
> I'd be glad to know since my interest in BeOS in _only_ because of the
> potential good LIVE daw perdormance...
What do you need? Rock solid audio in -> audio out processing with
around 10 ms latency at 80% CPU load shouldn't be a problem. (You'll
have to ask Benno about the results of his full duplex streaming tests.
The 4.3 ms is from the thread to the output, so one or two buffer
fragments will have to be added to handle full duplex reliably. [3
fragments are used in the output-only test.])
With RTLinux, the limit is the sound card's smallest DMA burst size
and/or internal buffering. I've tested .4 ms (in -> out) on AudioPCI,
and it should easily cope with .6 ms with 90% CPU load.
And there's another solution: Locking one CPU on an SMP box for signal
processing. You can stay in user space, so memory protection is still
there, and if you go all the way and actually use a kernel patch that
keeps all non-SCHED_FIFO tasks off your RT CPU, you can get down to
latencies below a single sample frame. (However, that's kind of
pointless, as there's already a delay of at least 2 sample frames
because of the oversampling, and then there's the digital filters...)
//David
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST