[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] DSP testing

From: Peter Hanappe
Subject: Re: [fluid-dev] DSP testing
Date: Wed, 31 Mar 2004 15:54:01 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

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

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]