Subject: Re: [linux-audio-dev] Realtime
From: David Olofson (david_AT_gardena.net)
Date: Sat Jul 08 2000 - 05:03:46 EEST
On Tue, 27 Jun 2000, yodaiken_AT_fsmlabs.com wrote:
> We've been getting a lot of inquiries about RTLinux/Audio recently (esp.
> from Australia for some reason)
> and I'm curious whether people on the list are using it.
(I've been kind of busy and more or less away from the lists for a few
weeks, so I'm some 100-200 posts behind for the moment... *heh*)
Anyway, I *used* to do audio hacking under RTLinux, but I got
entangled with the mysteris of designing a usable event based RT
plugin + IPC API, which is required to produce anything but yet
another practically monolithic application.
Meanwhile, the lowlatency patch came up and turned SCHED_FIFO from
"acceptable for debugging" into "fully appropriate for production
systems", so RTL will only be required for the most extreme
situations, where significantly less than 3 ms input->output latency
is required.
> If not is there
> anything we can do to make it easier to use ? Is so, I'd really
> like to see what people are doing.
Well, I think something like that uniform Linux/RTLinux driver API I
was working on is required, as that would make porting just about any
driver to RTL trivial. Drivers are what's lacking - for the actual
applications, I think the RTL API is sufficient.
Hmmm... Possibly one problem: IPC between the user space parts (user
interface, disk access etc) and the kernel parts (audio
generation/processing) needs to become less RTL/kernel specific, so
that porting an audio engine from user space to RTL doesn't require
rewriting most of the IPC code.
If shared memory is used, pointers become a problem that the code
(either on the user space or the RTL side, or both) must deal with
explicitly all the time, as the user space app and the RTL threads
probably can't get the shared memory window to appear on the same
linear addresses. Using offsets instead of pointers in is one way that
I'm considering for my plugin API (MuCoS).
Using FIFOs is possible in some cases, but audio applications tend to
pass huge amounts of data around. As an example, a multitrack hardisk
recording/playback applications with an ultra low latency RTL
mixing/processing engine would move many channels of 44.1..96 kHz 16
or 32 bit data between the user space and RTL threads, so anything
like the buffer sizes used by normal FIFOs is insufficient. It would
force the user space thread to refill the FIFOs more frequently than
perhaps even the lowlatency kernels can handle. Also, the memory
copying overhead starts to get noticable at this kind bandwidth.
> FYI: Linux PPC now runs the RTLinux system without needing a patch.
> PowerPC performance has been quite impressive.
How about PPC G4? I'm particularly interested in AltiVec, and of
course, an architecture that doesn's suffer from all this IBM PC/x86
legacy stuff, inefficient IRQ handling and all other things we've had
to put up with. Any nice mainboards (SMP?) that would be suitable for
building high bandwidth RT workstations? All I've seen so far is
boards for embeded systems, and PCI "DSP" boards for Macs and PCs.
The latter ones seem cool, but I'm a bit worried about that PCI bus
bottleneck between the host and the boards...
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Sat Jul 08 2000 - 12:06:37 EEST