[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:18:21 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3

David Olofson wrote:
On Thursday 01 April 2004 03.00, Tim Goetze wrote:

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.

That would depend on what kind of sounds you're dealing with... In the case of strings, pads and other sounds that tend to be used for long notes, it's usually much worse if the notes are dropped.

Anyway, the usual approach is to handle Program Change separately, and make sure NoteOns are always hard RT safe, except when a Program Change is in progress. That is, when you get a Program Change, you do all the soft RT/non RT stuff, allocate objects, buffers and whatnot, so that subsequent events can be handled entirely in the audio thread once the patch is "loaded".

Many h/w synths disable voices and delay or drop NoteOns after a Program Change, but I guess people expect wavetable and virtual analog synths that are less than ten years old to be totally hard RT in this respect... Samplers are different, as they have to load tons of data from disk after a Program Change, even if they're "direct from disk" samplers. (That might change eventually, though. There have been computer mainboards with battery backed up DRAM for years, and flash technology is probably fast enough now for playing directly from flash.)


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.

Right. IMHO, this is especially important for games/multimedia engines, as you can't rely on shutting the audio subsystem down just to load/render some sounds. You're supposed to be able to load sounds and music while playing other stuff.

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've come to agree with the initial proposition of having a single
event FIFO to communicate with the audio thread.

When a program change comes in, the audio thread asks the soundfont
for the corresponding preset. The soundfont must respond immediately.
If the preset isn't loaded yet, it must call upon a worker thread
to do the job. This loading is the soundfont's business; the audio
thread doesn't care.

When a noteon comes in, the preset is asked to create and initialise the
corresponding voices. Again this call must be RT safe. If the preset
isn't finished loading, yet, the note may get dropped.

Sorry it took me so long to finally come back to the initial
proposition. It will give more work to the audio thread so the
load of the audio part becomes less predictable.

BTW, it's really rather useful to have a way of telling whether or not a sound or song is ready to play. If you can just send Program Change events without getting any "done!" response, you have to rely on the same approach you use with h/w synths and samplers: Have a bar of silence after a Program Change event... (Which doesn't even work reliably with samplers, as sounds may take ages to load.)

Good point. This notification may be asychronuous, so the caller will
have to pass a callback function.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---

fluid-dev mailing list

reply via email to

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