Subject: Re: [linux-audio-dev] Realtime
From: yodaiken_AT_fsmlabs.com
Date: Sat Jul 08 2000 - 16:55:08 EEST
On Sat, Jul 08, 2000 at 04:03:46AM +0200, David Olofson wrote:
> 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.
Look at UDI. We are looking at it very seriously.
> 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.
The simplest method is a character device interface. Can you tell me what
is unportable about that?
> 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).
A litle indirection goes a long way here.
> 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.
We see around 200MB/s on a PII and 300 on PIIIs but fifos have a log
of room for optimization in them.
>
>
> > 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
Yup.
> 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...
Apple claims a dual will be out soon.
-- --------------------------------------------------------- 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 : Sat Jul 08 2000 - 17:13:05 EEST