>I don't think I was thinking about the same thing as you were :)
>
>It would run basically with "while (ready) run_cycle();". ready would
>be controlled by either the mic input, or the soundcard output, making
>sure it produced data until the requirements were met.
Again, in the LAAGA model (not Abramo's), components/clients/plugins
don't know *anything* about "mic inputs", "soundcard outputs", etc.
There is just one engine, abstracting a real audio interface (and
recall that ALSA itself might be hiding just part of a h/w audio
interface or combining several together to form one) into a set of
channels.
>> to reiterate, all LAAGA offers is:
>>
>> * abstraction of the audio h/w into a series of mono, 32 bit float
>> channels along with functions to write/read data to/from them.
>> * totally synchronous execution of all clients/plugins; each plugin
>> has its "process()" function called by the engine at the right
>> time.
>> * data sharing via internal busses accessed via the exact same
>> mechanism as physical channels.
>>
>> nothing (or almost nothing) more.
>>
>> does that make it any clearer?
>
>I think so. It's basically you're just dealing with symmetric
>internal stuff, leaving assymmetric and external stuff to something
>else entierly. right?
not really. there are no asymmetric cases. but yes, anything external
(not running in the engine's audio thread) is not part of the API.
--p
