[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [fluid-dev] DSP testing
Re: [fluid-dev] DSP testing
Thu, 01 Apr 2004 12:18:21 +0200
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
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