Re: [fluid-dev] DSP testing

[Peter Hanappe]

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.
>
>
> Right.

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.

Cheers,
Peter


> //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
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/fluid-dev