Re: [fluid-dev] DSP testing

[David Olofson]

On Thursday 01 April 2004 11.38, Peter Hanappe wrote:
> David Olofson wrote:
> > On Wednesday 31 March 2004 19.55, Peter Hanappe wrote:
> >>1) When a noteon event comes in, the user thread calls the
> >>soundfont object to initialise the voices. The soundfont object
> >> can do the necessary housekeeping.
> >
> > This suggests that "initializing SF voices" is not a real time
> > safe operation. Sounds like pretty bad news to me... What am I
> > missing?
>
> Initializing the voices currently is RT safe. In future versions
> I would like to give the soundfont more flexibility on the handling
> of samples. I'm thinking in particular of streaming samples instead
> of keeping all samples in RAM.

You need a pre-caching scheme to make that RT safe, or even seriously 
useful at all. Have a look at LinuxSampler, which does exactly this.


> If you initialise the voices in the
> audio thread, the soundfont has no choice: it has to be RT safe.
> If you do it in the user thread the soundfont can choose between
> dropping a note but reply fast, or loading the sample from disk and
> possibly introduce a delay.

I don't see why you have to bundle sound loading/selection (usually an 
"off-line" operation) with NoteOn events. This problem doesn't really 
exist in traditional hardware and software synths and samplers, as 
voice initialization is always RT safe as soon as a Program Change 
operation has finished. (Though, there's still a problem with MIDI 
samplers, as there's no standard way of telling when they're done 
loading...)


> > What happens when you try to play these sounds from MIDI files
> > using the internal sequencer? Isn't the sequencer running in the
> > audio thread?
>
> No. Nor the sequencer, nor the midi input are run in the audio
> thread. They have their own thread.

Why? It just complicates things in my experience...


[...]
> > Why separate FIFOs for voice allocation and events? Do events
> > come from a different (perhaps more real time) context? If so,
> > what's the point, if the whole "note on" operation depends on
> > stuff from both FIFOs?
>
> Both the voice allocation and the voice_group_on event come from
> the same context. Let me illustrate why I thought the
> voice_group_on event is needed. Imagine there is no voice_group_on
> event. A noteon creates 2 voices. The first voice is initialized
> and put into the fifo. Then the audio thread wakes up and starts
> the first voice. When the audio thread finishes, the second voice
> is initialized and put into the fifo. Next time the audio thread
> wakes up the second voice will be started, but it will have a 64
> sample delay with the first voice.
>
> To avoid that, both the first and the second voice aren't started
> until the voice_group_on event is received. This event is posted
> by the user thread in the noteon function, right after creating and
> initialising the voices.

I see. I avoid this problem entirely in Audiality by using timestamped 
events, and by running the sequencer and "patch plugins" (what turns 
high level MIDI style events into voice level operations) in the 
audio thread. If I start N voices with the same timestamp, they're 
guaranteed to start playing at the very same sample. No explicit sync 
needed, since everything's in one thread.

That said, the sync issue still applies when playing sound FX and 
stuff from another thread. However, the "standard" solution is to 
implement multichannel sound effects as instrument patches, so they 
can be controlled with single events.

In future versions, I'll allow the use of scripting in the real time 
context as well. That should make it possible to have most of the 
sound FX logic run in audio context, so the game logic can send 
simple commands with no need for "group sync" and the like. (Well, 
that could be implemented as well if desired, of course...)


//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 ---