[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 11:50:31 +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]

Josh Green wrote:

I have a feeling there are probably some issues with stereo output in
regards to the phase offset between right/left speakers. Is there
currently a way to guarantee multiple voices to all start at the same
time? Playing the same note can often sound different for each note on.

No, there currently is any way to guarantee they start together. It
could happen that the audio thread intervenes between the initialization
of the first voice and the initialization of the second voice, in which
case the two voices are shifted by 64 samples. I should test whether
this really happens and think of a way to fix it if it does. Good point.

i think that the safe way to handle this is to decouple the synth
interface (*_noteon() and friends) from the engine. a possible
solution is to queue commands in a lock-free FIFO that the engine
thread reads from at the start of an audio cycle, and that
fluid_synth_noteon() and friends write to. thus, complete execution
of noteons and the like is guaranteed.

I would like to avoid lock-free FIFOs if possible. FIFOs don't make the
design of the synthesizer simpler. I think it is possible to do without.
I'm thinking of using "voice groups":

1) make noteon() atomic. (currently, the synchronization is up to the
   calling thread but that should be changed).
2) all the voices created during the call to noteon are in the same
   voice group and should be phase locked.
3) a voice starts playing when the voice is turned on and when
   the voice group is turned on. Currently, only the voice is checked.

Changing and checking whether a voice group is on/off can be done using
atomic operations. No need for locking, no need for FIFOs.

I made the changes above in my local copy of fluidsynth. There weren't
that many modifications to be made and all still seems to work. I
can commit it to CVS if you want to check.

this would also imply that there is no interference problem with
acquiring the synth engine lock when issuing an engine command. in the
current fluid incarnation this is a potential cause of sound dropouts:
command thread acquires synth lock, audio interrupt, audio engine
wants lock, audio thread goes to sleep, lock is released in command
thread, audio wakes up -- this can cause a significant delay.

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.
While playing, the user thread may change some generator
value. This is just a matter a writing a new float value in the voice
structure. This can be done atomically, too (no?).

I hope this analysis is correct (and clear). The current implementation
doesn't use explicit atomic operators to set/get a value. It uses plain
integer or float assignments and reads but that can be changed and
doesn't alter the analysis above.




reply via email to

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