Actually, it may not be all that hairy after all. Consider these
events:
XAP_A_BUFFER
Function: Someone just gave you an audio
buffer of the standard size used
by the Host. It's all yours now;
do what you like with it. Don't
forget to free it eventually!
Arguments: Pointer to the buffer.
Cookie. (So you know what it's for.)
Size. (# of BYTES actually used.)
XAP_A_REQUEST_DATA
Function: Ask for a number of buffers.
The API doesn't guarantee anything
about when they'll arrive; that's
something you and that guy in the
other end will have to discuss.
Arguments: Size. (# of BYTES of data you want.)
Cookie. (So the other guy knows)
When. (Your deadline. Be sensible...!)
If you want data streamed to your plugin, you'll send
XAP_A_REQUEST_DATA events, and (eventually) receive XAP_A_BUFFER
events. Connections are made by the host (as usual), although each
streaming connection actually needs *two* connections; one in each
direction. (The API should probably cover this, so hosts and/or users
don't have to mess with it manually.)
Ok?
//David Olofson - Programmer, Composer, Open Source Advocate
.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
.- M A I A -------------------------------------------------.
| The Multimedia Application Integration Architecture |
`----------------------------> http://www.linuxdj.com/maia -'
--- http://olofson.net --- http://www.reologica.se ---
