Re: [fluid-dev] DSP testing

[Peter Hanappe]

David Olofson wrote:
> On Wednesday 31 March 2004 15.54, Peter Hanappe wrote:
> [...]
>
> > I overlooked  the case where the audio thread can be interupted,
> > which can happen if fluidsynth runs without priviledges. You are
> > quite right that that case poses a problem. A complication I see
> > with the fifos, though, is that when the user thread has to kill a
> > voice, it send the 'kill' request to the audio thread and then has
> > to wait for the audio thread to confirm the request. So you have to
> > introduce synchronization even if you use lock-free FIFOs.
>
>
> Well, that would depend on the level of the communication. If voice 
> stealing is always managed by the audio thread, this problem is 
> avoided.
>
> However, if you do it that way, you probably need a virtual voice 
> address space of sorts.
>
> We invented the term "Virtual Voice ID" (VVID) in the XAP discussions. 
> A VVID is a handle (actually an array index) that comes with a void 
> *. When the "sender" needs a voice, it allocates a VVID for it and 
> then uses that from then on, when talking about the voice. The 
> "receiver" (the audio thread in this case) would normally allocate a 
> physical voice when the new VVID is first used. The receiver may use 
> the VVID void pointers internally for fast addressing. (voice = 
> (MY_voice *)host->vvids[event->vvid] instead of scanning voices for 
> event->vvid.)

It's true that it would be nice to have an ID of some sort. FluidSynth
may create several voices for a single noteon so the ID should refer
to all of them. Fortunately, I introduced the voice groups this
morning :) So the ID could refer to the voice group. That would imply
scanning voices for group_id instead of an array access as what you
propose.

Considering the discussion so far, I would suggest the following :

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.

2) These voices are pushed into the "voice" fifo.
   Note that these voice objects are not taken from the voice
   objects that the synthesizer uses internally. They are taken
   from a voice heap, let's say.

3) All voices created in a single noteon event belong to the same
   voice group. The user thread can choose an ID number for this voice
   group but the ID has to be unique (a counter will do)

4) In addition to the voices, the user thread sends an
   "voice_group_on[id]" event in a second fifo, the "event" fifo.

5) The audio thread, in every loop, picks up the initialized voices from
   the voice fifo and tries to schedule them for synthesis. The audio
   thread may have to kill voices if the maximum polyphony is reached.
   The audio thread actually copies the data from the initialised voice
   into a voice used internally by the synthesizer. That way the voice
   taken from the fifo can stay in the fifo for reuse.

6) The audio thread, in every loop, picks up the events from the event
   fifo. Upon reception of the "voice_group_on" event, the audio thread
   turns on all the voice in that group.

7) Other possible events include "noteoff[chan]",
   "update_param[chan,num]", and a couple more.

It turned out to be a bit of a long resume but I hope it is
understandable.


>>I think the easiest solution may be to use a mutex if the audio
>>thread does not run with high priority and keep things as they are
>>now if the audio does have a high priority.
>
>
> Risky. AFAIK, most operating systems won't *guarantee* that so called 
> real time threads (meaning soft real time threads) cannot be 
> preempted by other threads at any time. "Real time priority" usually 
> just means higher priority, and unlike SCHED_FIFO on Linux, that 
> doesn't necessarily imply that the time sharing is completely 
> bypassed.
>
> That is, at some point, the scheduler may decide that your privileged 
> "RT" audio thread is hogging the CPU too much, and then it will be 
> preempted every now and then - despite your efforts and beyond your 
> control.

Agreed. (Well, Linux guarantees it. What other OS do we need? ;)

So FIFOs will be the way to go then.

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