[Top][All Lists]
[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 ---
- Re: [fluid-dev] DSP testing, (continued)
- Re: [fluid-dev] DSP testing, Tim Goetze, 2004/03/30
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31
- Re: [fluid-dev] DSP testing, Josh Green, 2004/03/31
- Re: [fluid-dev] DSP testing, Tim Goetze, 2004/03/31
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31
- Re: [fluid-dev] DSP testing, Tim Goetze, 2004/03/31
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31
- Re: [fluid-dev] DSP testing, Tim Goetze, 2004/03/31
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31
- Re: [fluid-dev] DSP testing, Tim Goetze, 2004/03/31
- Re: [fluid-dev] DSP testing,
David Olofson <=
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31
- Re: [fluid-dev] DSP testing, Antoine Schmitt, 2004/03/31
- Re: [fluid-dev] DSP testing, David Olofson, 2004/03/31
- Re: [fluid-dev] DSP testing, Josh Green, 2004/03/30
- Re: [fluid-dev] DSP testing, Peter Hanappe, 2004/03/31