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: Jaroslav Kysela (perex_AT_suse.cz)
Date: la loka   09 1999 - 17:26:24 EDT


On Sat, 9 Oct 1999, David Olofson wrote:

> On Sat, 09 Oct 1999, Jaroslav Kysela wrote:
> [...]
> > I would like to see, if we join our efforts to one background sound
> > project and create good universal sound API for Linux, because there is
> > really only few active Linux audio developers around.
>
> So would I. I think a universal "IPC" API for multimedia would help things a
> lot when integrating applications and engines into The multimedia system. I'm
> not sure exactly how this fits with the ALSA API, but it seems like the
> concepts are rather similar in many ways.
>
> The question is, where does the new API fit in?
>
> IMO, there should be a Multimedia Communication System (or whatever)
> that lives in kernel space and provides
>
> 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.

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.

> 2) An API layer that implements a flexible buffered event system, and
> data format independent streaming capabilities on top of that IPC
> protocol. (Most of the frequently used stuff, like event handling,
> should be done in inline code for performance.)

Yes, this sounds good.

> 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).

                                                Jaroslav

-----
Jaroslav Kysela <perex_AT_suse.cz>
SuSE Linux http://www.suse.com
ALSA project http://www.alsa-project.org


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