[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: Thu, 01 Apr 2004 12:45:09 +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'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.




reply via email to

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