Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sat Nov 18 2000 - 13:35:16 EET
( ... MCOP vs libsigc vs MAIA ... )
I do not know MCOP and I have played around only very little with libsigc++,
but what we need is a communication system which must be very lightweight
even when making/destroying connections (since we want to place patches in real
time).
Plus for low latency apps, we need lock-free communication between the
RT and non-RT parts of the app.
For example a slider GUI element want to display the current volume value of
an audio track, which gets automation data from another source.
In this case I want that the GUI slider gets all new volume values from the
audio app, to reflect the "motorized-fader" effect.
With a lock-free fifo this would be ideal since even if the GUI element is non
RT, it does not loose any data opposed to the model where you are simply using
a shared variable.
(Plus the shared variable will not work with datasets > 32bits because of the
atomicity problems)
The same must work in reverse order (a slider controlling a volume value):
use the same fifo approach.
If I want network transparency, I simply write a "proxy-element" which
has as input the lock-free fifo and as output a network connection or vice
versa.
I admit that this asynchronous communication method is not easy to deal with
(even on the same machine) since receivers need to be woken up or do active
polling.
Having investigated the speed of IPC methods (I got some advices from kernel
guys too), the only thing you can tolerate is to write a byte to a unix pipe,
where the receiver gets woken up after sleeping in a blocking read.
And in order to avoid zillions of calls to write() within the RT audio thread,
we should delegate the wakeup of receivers to a butler thread which gets woken
up by the RT thread and gets informations about whom to wake up using shared
mem.
That way the RT thread can send data to a huge amount of receivers without
fearing a dropout.
Handling the sending of data from non-RT elements to RT-elements is easier,
since all the non-RT element has to do is to write to the lockfree-fifo.
The RT-element will poll for new data at every processing iteration.
(in the case of audio each time a fragment is played).
Now my question are MCOP or libsigc++ capable of such things ?
(I mean: lock-free async communication plus VERY lightweight functions to
to connect/disconnect senders with receivers).
If these APIs are not suitable for this, then we have either to change them or
write one from scratch.
David O. how would MAIA compare with MCOP/libsigc++ in that area?
Without these characteristics, my "virtual studio" idea cannot be implemented.
(You know: all "applications" runs as "plugins" of a main host, which
never never never blocks (*) (mark the last 4 words .... ) )
comments ?
Benno.
(*) audio I/O is the exception but we all know that this provides a good
determinism. (see low latency tests))
This archive was generated by hypermail 2b28 : Sat Nov 18 2000 - 12:49:54 EET