Re: [linux-audio-dev] MIDI routing, FIFO's etc.

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] MIDI routing, FIFO's etc.
From: David Olofson (audiality_AT_swipnet.se)
Date: la loka   09 1999 - 20:29:39 EDT


On Sat, 09 Oct 1999, Jaroslav Kysela wrote:
> > 1) A transparent shared memory based IPC protocol, tailored for real
> > time streaming and communication. This should be a client/server
> > style system where kernel modules, drivers and user space
> > applications and engines can register, to provide and/or use real
> > time services. (My idea is that this shouldn't really be directly
> > multimedia oriented.)
>
> You described already implemented ALSA sequencer :-) If we separate audio
> things from the sequencer concept and add support for shared memory
> (accessible from both kernel and user space simultaneously) - IPC shared
> memory probably can't be directly accessed from kernel space, we can use
> the current code for any applications as a general event router.

That sounds very interesting. :-)

> I think that the big problem will be with the memory allocation, because
> the allocation must be done inside kernel (use mmap from the user space?).
> It's problem #1 and we should solve it firstly.

There is a module called mbuff that's used with RTLinux for this
purpose. It's based on the "heavy wizardry" in bttv.c, and I think
the module should work w/o RTL... (Memory allocation from the
standard kernel heap can never be hard real time anyway.)

> > 3) A plug-in API that interfaces nicely with the API layer, so that
> > plug-in hosts don't have to do lots of translation.
>
> This also sounds good. I would be very happy, if I'll work only on clients
> (lowlevel drivers) for some realtime event system. I must do some other
> thoughs for all sound APIs (mixer, digital audio streaming, MIDI).

Your drivers become clients, and need only care about the hardware
and the API. As opposed to plug-ins (that are callback functions,
processing one full cycle [buffer] at a time), clients can decide for
themselves when their cycles end, so you kind of get both FIFO
functionality and shared memory performance with the same API.

I think we will have a preliminary spec of the low level part of the
API soon, but so far, most of the info is in the form of posts on
linux-audio-dev...

//David

 ·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
    ·Rock Solid David Olofson:
    ·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
    ·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
    ·Open Source ·Singer/Composer


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST