Subject: Re: [linux-audio-dev] aes: new model
From: Paul Davis (pbd_AT_Op.Net)
Date: Fri May 18 2001 - 16:13:25 EEST
>> Note that a Driver is a kind of Plugin. So, the Engine builds a signal
>> graph for the current interconnections between all the ports, and
>> executes all Plugins (including both the Driver and regular Plugins)
>> in the "correct" order (if such a thing exists).
>
>Sorry, I think I missed something, what is the significance of a Driver?
>Are they responsible for doing the i/o?
Yes. In a formal sense, they are the only kind of Plugin that is
allowed to contain blocking behaviour, which is expected to be caused
by waiting for the h/w associated with i/o to be ready to do
i/o.
Regular Plugins only have a "process()" function which is expected to
execute without blocking behaviour. Given that we're going to be
willing to support MP, "blocking while my associated process executes"
is acceptable.
In the real world, a Driver object is what handles the interaction
with a real I/O device (via the usual OS abstractions), be it a disk,
an audio interface, a network or a Frob.
So, a Plugin is an object that:
* delivers data to its output ports AND/OR
* receives data from its input ports
A driver is an object that does what a Plugin does, plus:
* waits for some condition to be satisfied (e.g. h/w is ready for I/O)
In my current source, there is one driver, named AlsaDriver, and one
plugin (Ardour).
>Speaking of which, what do people think of having MIDI as a 1st class
>thing (stream, events, whatever), as audio is?
I am absolutely opposed. MIDI should be removed from the core of any
not-purely MIDI API. Its fine to support MIDI, but ideally it would to
be translated into a format that is not MIDI before it gets used by
objects internally. I made the mistake of supporting MIDI all the way
"down" in Quasimodo, and I consider it a serious error. MIDI is too
coarse and too limiting a protocol to be allowed 1st class
status. SKINI would be OK, I think.
A much better idea is to support byte-formatted data on ports. Plugins
that wanted to exchange MIDI could do so using such ports, but there
would be no explicit 1st class MIDI ports within the API.
>> The engine no longer supports busses directly. Busses would be
>> supported by a specific plugin, whose job was simply to declare N
>> inputs and N outputs, and to run a process() function that did
>> basically nothing. There's work to do on the details of this, but the
>> idea has great appeal for me, and may help settle the argument over
>> patchbay/bus designs.
>
>Sounds good. How is the routing going to be specified? Or is that an
>implementation detail ;)
Its an implementation detail. Something calls a function like
Engine::make_port_connection (Port *, Port *), and the rest is taken
care of. You can connect any two Ports as long as their
characteristics allow it. So you can do a direct patch from a
output port on a softsynth to an input port on an HDR, or you can do
an indirect patch via the ports on a bus plugin.
I thought I had it all worked out, but now I am trying to figure out
how to efficiently execute the signal graph at the same time as
supporting an rather nice model involving a matrix of port connections
with gain values for each element (input port,output port) of the
matrix (idea attributable to bill evans). I'm not sure its possible to
be memory efficient with the matrix model.
--p
This archive was generated by hypermail 2b28 : Fri May 18 2001 - 16:52:00 EEST