fluid-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] DSP testing


From: David Olofson
Subject: Re: [fluid-dev] DSP testing
Date: Wed, 31 Mar 2004 18:13:54 +0200
User-agent: KMail/1.5.4

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


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


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





reply via email to

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