Re: [fluid-dev] DSP testing

[David Olofson]

On Thursday 01 April 2004 12.18, Peter Hanappe wrote:
[...]
> > BTW, it's really rather useful to have a way of telling whether
> > or not a sound or song is ready to play. If you can just send
> > Program Change events without getting any "done!" response, you
> > have to rely on the same approach you use with h/w synths and
> > samplers: Have a bar of silence after a Program Change event...
> > (Which doesn't even work reliably with samplers, as sounds may
> > take ages to load.)
>
> Good point. This notification may be asychronuous, so the caller
> will have to pass a callback function.

OTOH, do you really care about this notification unless the audio 
thread is actually running? Also note that the audio thread will 
normally run only for a very short moment at a time, so you can 
effectively assume the processing of each audio fragment is a 
periodic event with zero duration.

That is, you may as well pass "worker finished" notifications as 
events that the audio thread reads next time it runs. It won't do 
anything before then anyway.

For the XAP plugin API, I suggested a simple worker callback API, 
using a host call to fire callbacks off to run in another thread, and 
the normal event system for passing notifications. (It makes no sense 
to call into a plugin, as it can't do anything before it's process() 
function runs the next time anyway.) I'm going to use the same 
approach in Audiality, for FX plugins, AGW rendering (Algorithmically 
Generated Waveforms; scripts, that is) and other stuff. Easy to 
implement, and it keeps the inter-thread sync mess in one place.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---