Re: [fluid-dev] DSP testing

[Tim Goetze]

[Peter Hanappe]
>I overlooked  the case where the audio thread can be interupted, which
>can happen if fluidsynth runs without priviledges. You are quite
>right that that case poses a problem. A complication I see with the
>fifos, though, is that when the user thread has to kill a voice, it send
>the 'kill' request to the audio thread and then has to wait for the
>audio thread to confirm the request. So you have to introduce
>synchronization even if you use lock-free FIFOs.

with the FIFO scheme proper, the note <-> voice mapping is done
entirely by the audio thread. imagine the audio thread reading a
complete MIDI stream and acting on all noteon/off, controller etc
events, calling the equivalent of fluid_synth_noteon() itself.

if the public interface (the user thread) wants to start a note, the
respective function simply writes to the FIFO and lets the audio
thread do the rest of the work.

>I think the easiest solution may be to use a mutex if the audio thread
>does not run with high priority and keep things as they are now if
>the audio does have a high priority.
>
>Wadyatink?

nah ... i would not like such special casing. i still prefer the FIFO.
done right once, we'll never have to care about locking/sync issues
anymore.

i've been employing the scheme in various incarnations for a long time
now, with best results and minimum coding headaches. in fact my main
music project wraps fluidsynth with this scheme so i don't have to
rely on the synth to get the lock/sync issues sorted out.

but eventually, you're le patron. :)

cheers,

tim