Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Thu Nov 23 2000 - 16:57:08 EET
>> ignoring libsigc++ for the time being (because its not part of LADSPA
>> at all): the scheduling in my proposed system is actually extremely
>> simple:
>>
>> ALSA poll(2) support:
>> * wakes up a thread very fragment
>> * this thread handles the low-level interaction with the audio h/w
>> and calls the "run" method for the patchbay/router/host.
>>
>> The patchbay/router/router simply executes the "run" method
>> for every plugin connected to every input port, then
>> executes the "run" method for every plugin connected to
>> every output port.
>
>Well, this sounds simple enough, and seems to operate on unmanipulated
>data.
Actually, no. The router/patchbay provides two 2 lowlevel operations:
read_from_channel (size_t channel, Sample *buf, size_t cnt);
write_to_channel (size_t channel, Sample *buf, size_t cnt);
which do the necessary conversion to/from Sample. At this time
"Sample" is a float. If we ever get real 32 bit sample h/w, it will
become a double.
> On a very low level, too. It would even be possible, if you put
>that thing in a library to connect aRts to it as client.
for me, that circumvents the whole model of a patchbay. in the
physical world, the patchbay sits between the "real" ins/outs and
everything else - *nothing* else except cabling sits between them. i
think it should be the same in this "virtual"/digital realm as well.
that said, the question is: what *are* the "real ins/outs" ?
in a studio, typically that means the ins/outs on the mixer.
in a computer, i would tend to consider them the ins/outs on the audio
interface.
the problem is that i see both points of view as very legitimate. you
probably want most other "apps"/clients to connect to the mixer, not
the raw audio interface model. OTOH, there is no reason i can see for
preventing that.
>It's not my view of a virtual studio, though, where you would allow
>having a mixer as plugin, which would mean that apps should connect
>to the mixer, and the mixer mixes and connects its output to an effect,
>and the effect,... and so on.
>
>Of course, you *can* do all this by going repeatedly through the patchbay,
>but unless your patchbay then supports float i/o, and not operates on raw
>data, it will be very inefficient.
As noted above, it does operate on float i/o. And the model I have
for the setup you are describing is:
client1 client2 client3 client4 client5
\ | / | |
\ | / | |
|
mixer plugin chain |
\ | |
\ / /
\ / /
patchbay/router -----------------+
|
audio h/w
this model allows some "clients" (plugins in the low-latency worldview
i have) to connect directly to the patchbay, and others to connect to
other clients that do various processing for them. but there is no
heirarchy here: the mixer, plugin chains etc. have no clear temporaral
or priviledge precedence over anything else.
>My feeling is also, that it standarizes too little to make the audio apps
>really interoperate in a user-friendly way. They don't really talk to each
>other the way you describe it. They don't offer services to each other, like
>a harddisc-recording-services. It's not an API for component oriented
>programming, but one for using huge monolithic blocks together.
I'll comment more on this in my response to your other message. The
gist of my feeling about this is:
* for non-low-latency work, the MCOP approach seems very flexible
and appropriate
* for low-latency "dedicated h/w" work, component oriented
programming needs to be subsumed to a plugin model
I claim in my defense all the commercial implementations of DAW's. Not
that a million flies proves that eating shit is a good thing, but
there's also no smoke without fire :) I hope those two english
language aphorisms have some meaning to the non-native english
readers/writers here.
A final note: the ALSA library is also trying to do some of this. I'm
not sure what to make of all this.
--p
This archive was generated by hypermail 2b28 : Thu Nov 23 2000 - 17:43:53 EET