Karl MacMillan wrote:
>
> >From your example it appears that two things happen:
>
> - a flow waits for data until . . .
> - it is committed
>
> What is not clear is:
>
> - who commits the data (server or plugin)
> - who creates ('owns') the data buffers
> - how are data dependencies resolved
I think there is some big misunderstanding: soundbox API is an
application API.
soundbox *implementation* would use soundbox API for talk with internal
(nested) soundboxes, *and* a whole different set of helper functions to
do soundbox connections and other stuff needed for internal
implementation.
I've written that this a view from the opposite edge of LADSPA (or even
LAAGA, if I was sure to understand exactly what it is ;-)
I wanted to focus on an external API suitable for talking with hardware,
plugins, complex audio components, control panel, visual scopes, etc.
taking in consideration all needs (multi threading/processing, parallel,
N/M connection, lowest memory footprint, etc.)
Immediately after some agreement on the external side we can write down
the internal side design of soundboxes.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
