Re: [fluid-dev] DSP testing

[Peter Hanappe]

Tim Goetze wrote:
> [Peter Hanappe]
>
>
> > I don't think there's a need for locking anyway. (BTW, I've commented
> > out the use of the synth->busy lock in fluid_synth.c). I'll try to
> > explain. The main data structure shared between the user thread and the
> > audio thread is the voice structure. When the voice is not
> > playing, the user thread can initialize a voice and then toggle the
> > playing state. This can be done atomically. Once a voice is playing the
> > audio thread will start accessing it.
>
>
>  but what happens when a voice needs to be killed because a noteon
> demands more voices than the polyphony setting allows? your scheme
> requires this to happen in the user thread.
>
>  now imagine the audio thread gets preempted after having decided a
> voice is valid to play, i.e. in the middle of an audio cycle (we're
> not always running privileged, so this can happen). before the audio
> thread is woken again, the user thread decides to kill the voice and
> reuse it.
>
>  things get very messy now because the audio thread completes the
> audio cycle with some initialization done on the previous contents of
> the voice structure, which are not valid with respect to the current
> contents of *voice. the actual behaviour depends heavily on the
> ordering of the audio cycle code, en tous cas it's not predictable at
> all.

It's true that I did assume that the audio thread runs with higher
priority than the user thread such that the audio thread can preempt
the user thread but not vice versa. This is currently the case if
the synthesizer runs with super-user priviledges. I think that in that
case, my analysis is okay.

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.

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?

Cheers,
P

> cheers,
>
> tim