Subject: [alsa-devel] Re: [linux-audio-dev] MIDI routing, FIFO's etc.
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka 10 1999 - 12:52:16 EDT
On Sun, 10 Oct 1999, Jaroslav Kysela wrote:
> On Sun, 10 Oct 1999, David Olofson wrote:
>
> > > 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.)
>
> I'm not sure, if using physical memory for events (my proposal and
> probably mbuff does this, too) is a good idea. The question is, how long
> will be an event. I'd like to see an event for complete wavetable
> instrument (tens of megabytes). If we will use only physical memory
> allocation and an user have only little memory, it will not work, but it
> works perfectly with current implementations which use the virtual memory
> (swap).
That will have to be an API extension in that case... What we're
dealing with is a real time event system that's primarily designed
for efficient communication with plug-ins. Actually, it won't even do
function calls when allocating memory for events most of the time...
> Onother thing: the process security. Do you thing that one shared memory
> heap is a good solution for multi user / multi tasking system? I don't.
> The memory heaps could be shared only among participants, but it's a
> question, how to do it (duplicate information? - another memory wasting).
That's a serious problem, and the question is; is it even possible to
run a system of this kind efficiently without compromising security
in some way? Sure, it would be nice to make sure no other user with
access to the "Multimedia Communication System" can connect to your
processing nets without permission, but is it worth the performance
impact?
There is one thing that may help, though; it wouldn't be a big
problem to have multiple memory areas for the communication system.
That would eliminate the possibility of tasks accessing things
without authorization, by simply controlling the access of the memory
areas. Communication between plug-ins, clients and servers (or
whatever we'll call them) across the memory areas would mean
copying. (Event system firewalls are possible...)
Is that cost significant? Will users on the same system really
interconnect their applications with so many connections/high
bandwidth that it matters?
> I also think that we should cooperate from beginning with Linus and Alan
> Cox to make sure, that this code will be included into the standard kernel
> tree.
That would be good, yes... I think it's time to write a
comprehensible, compact document as soon as the API starts to get
into the alpha implementation stage.
> A little dream:
>
> Event - picture 768x576 from grabbed from the BTTV driver 8-bits per color
Sorry... Events can never be that big due to the performance hit that
would mean for plug-ins and applications that need to send thousands
of events, and still be capable of hard real time.
But... There are data streams. In the case of the picture; that's
*exactly* what I had in mind for this part of the API - apart from
streaming audio, of course.
> Event - Piano instrument 96kHz, 24-bit resolution
I guess off-line streaming could handle that... Things that can't be
done in a single process cycle doesn't fit well with our definition of
plug-ins (callbacks), but it should be possible to implement as one
of the protocols on top of the event system. (Which is used by
clients, servers etc, in addition to plug-ins.) The audio streams
that we have been thinking about mostly so far are constant rate, and
they're strictly bound to the time base of the communicating
parties. However, the idea of supporting variable rate streams have
been in the back of my mind for long, and extending it to cope with
huge data buffers doesn't seem impossible. Not hard real time, but
still the same API... :-)
//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
------
To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST