Re: [fluid-dev] DSP testing

[Peter Hanappe]

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.

Cheers,
P

> cheers,
>
> tim