Re: [fluid-dev] DSP testing

[Peter Hanappe]

Tim Goetze wrote:
> [Peter Hanappe]
>
> > I'd suggest that the synthesizer has an internal set of voices that
> > it uses for the audio synthesis. When the audio thread picks up a
> > voice from the FIFO, it copies the voice's data to one of the
> > internal voice and leaves the voice in the FIFO for reuse.
> > The FIFO could simply be a round-robin buffer with a read and a
> > write pointer.
> >
> >
> > > do you think that instead it would be feasible to split the voice
> > > initialization work into non-RT and RT parts?
> > >
> > > this way, the user thread could ask the soundfont to prepare the
> > > samples and do whatever else non-RT needs to be done, without actually
> > > touching the voice struct. after this call returns, the user thread
> > > writes the noteon to the stream, and the audio thread then asks the
> > > soundfont to do the rest of the setup, knowing for sure that this call
> > > is RT-compliant.
> >
> > I've thought of that. But when the audio thread picks up the voice,
> > how can you guarantee that the soundfont and it's sample cache are
> > still in the same state (there could have been MIDI program change
> > in between that messes things up).
>
>
> i've been thinking about this for a long time, and came to the
> conclusion that if the soundfont is not ready to play a note in
> realtime, that noteon must be dropped silently. allowing arbitrary
> jitter in the timing of notes is - musically - even worse than being
> quiet for a brief time after a program change.

As David says in the follow up mail: it may depend on the type of sound.

> if a soundfont manager needs time to process a program change, this
> must not interfer with either the audio thread (obviously) or the MIDI
> feeding thread. the latter is not so obvious, but if we allow the
> soundfont loader to block (operate in) the MIDI thread, timing
> accuracy is ruined which we can - i think - not tolerate.
>
> we can conclude that a soundfont manager that does disk access (or
> other potentially blocking calls for that matter) needs to run in its
> own thread since it can't operate in either audio or MIDI context if
> we want jitter-free timing and no audible dropouts.
>
> the sf manager thread then needs to be notified of program change
> via another decoupling (simply reusing the FIFO prototype comes to my
> mind) and go about its business in the background.
>
> when the next noteon comes in, the manager hopefully has all the
> preset data ready. if not, we simply drop the noteon as discussed. if
> yes, we can play the note right away, and it doesn't really matter
> whether we make the decision in MIDI or audio context.

I agree to that.


Cheers,
Peter

> cheers,
>
> tim