Subject: [linux-audio-dev] MuCoS: New "radical" changes!
From: David Olofson (audiality_AT_swipnet.se)
Date: ma loka 18 1999 - 22:57:05 EDT
Inspired by an idea of Roger Larsson's (private mail in swedish), and
my coming to the conclusion that there is only
1) everything fixed size,
2) virtual memory with hardware support, or
3) memory segmentation handled by the code,
I decided to give the third alternative a shot.
Motivation:
1) is to restrictive, and will become a cumbersome legacy problem
sooner or later, if not right from the start. There is a reason why
I'm still thinking rather than having yet another VST style engine
in running code. (Perhaps I'm expecting too much from the new API,
but hey, you go ahead and code something in the classic style while
I "waste" my time! If I come up with something useful, and use it if
you like... I like designing, so I don't mind. :-)
2) is too expensive on most architectures (modifying + flushing VMTs),
and also requires a kernel hack if we are to use it for real time.
(Unless there is a way to lock memory *before* you malloc() it...)
Solution (?):
Now, 3) is usually nothing but a major PITA. (Remember 16 bit
protected mode, or perhaps even real mode? Or the REU for the C64?)
However, as we're dealing with a) events and b) buffers anyway, it
doesn't have to make all that much difference.
(Beware, Paul; you won't like this! ;-)
We had this discussion on events, some ideas about using events for
audio buffer info and so on. Roger had this idea of a different
design, that's even more event oriented than my plans so far... And I
realized that there is a use for the "new audio buffer" event:
eliminating the memory allocation problem. Well, almost. It's no
magic, but it'll solve a very serious problem, and brings some bonus
in the form of simplifying dynamic streaming rate support.
1) Have a "new buffer for channel X starts now" event, and
just handle it as usual in process(). (Possibly, the
event can handle multiple channels - a performance hack
for the average case.)
2) Make the engine insert those events when needed - in the
normal case; first in the event input buffer.
3) Have fun!
There is now no restrictive connection between the stream buffer size
and the cycle rate. (Other than that using a buffer size that's a few
samples short of the cycle time is a bit inefficient. However, it
still means only some extra events - no function calls with the
complexity of getting it done right in the engine.)
BTW, this eliminates the need for public stream ports in a quite
natural way. A stream port becomes an invisible abstraction accessed
through events, and the implementation details can be tailored for
speed or convenience as the plugin hacker desires.
Oh, the GIMP uses tiled buffers when communicating with it's plugins
these days. But that's for a slightly different reason; huge images
don't fit in RAM, and this way is a lot more efficient than
swapping... It works (obviously!), but I'd guess it means a little
extra trouble for them, compared to our case - we have to deal with
lots of buffer boundaries all the time anyway.
"The Right Thing" would be way too inefficient, and I still don't
think that "Worse Is Better" to the extent of going back to the fixed
size everything model. I think this seems pretty close to "The Right
Thing", even if the "new buffer for channel X starts now" event
perhaps looks like a "Worse Is Better" style thing... If it can't be
logically perfect, let's at least make it simple and efficient. :-)
//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
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST