Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Sun Nov 19 2000 - 16:07:48 EET
Hi!
On Sat, Nov 18, 2000 at 12:35:16PM +0100, Benno Senoner wrote:
> ( ... MCOP vs libsigc vs MAIA ... )
>
> 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.
>
> [...]
>
> 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.
Well, the current code would not only write a byte, but would write
<mcop header><destination><new value>
12 bytes 8 bytes 4 bytes for float
to the socket, in this case a unix domain socket. For an FFT scope with
18 bars, it would look like
<mcop header><destination><new value>
12 bytes 8 bytes 4 bytes*18 for float
Probably, you could also make it very simply merge multiple outgoing
messages, instead of sending them one-by-one, into one write.
Now, if you say that the transfer of these bytes is a problem, and you
would rather only transfer one byte, and do the rest via SHM, you should
write a new MCOP transport, and it would work via SHM then, making large
amount data transfers cheap, too.
> 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).
Making connections in MCOP is not that cheap, they do involve mallocs and
stuff like that, but well, if you really have problems with that, you are
probably better off trying to optimize these parts than writing an own
middleware.
> 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 .... ) )
There might be some work to do on never blocking. For instance, currently
making a connection from inside artsd to the outside world involves seeing
if the outside world is still there (which means, blocking lookup).
Threading could be used solve this, or other (state-machine-driven)
approaches.
Cu... Stefan
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Sun Nov 19 2000 - 16:45:57 EET