Re: Application with multiple IO callback on multi-processor
Re: Application with multiple IO callback on multi-processor
- Subject: Re: Application with multiple IO callback on multi-processor
- From: Jeff Moore <email@hidden>
- Date: Fri, 8 Apr 2005 12:37:46 -0700
I think you misunderstand what I'm saying. I did not say that it
wasn't possible to have multiple IO threads in single process.
IOAudio drivers are already able to handle the mixing and, with a
little retooling, the HAL could easily handle the thread management.
What I said was that the bang for the buck is fairly small. Most
audio engines out there are not set up to handle the complexity of
multiple concurrent IO threads. It is not a trivial task to change an
engine to be able to take advantage of such a feature. Plus, you open
the door to more performance problems than you solve.
The fact is, you don't need multiple IO threads to take advantage of
multiple processors. There's nothing the app gains from this that it
couldn't do better by managing it's own threads. The primary reason
why is that they don't have to run in the real time band. Rather, the
knowledgeable app can schedule it's worker threads at lower priority
to make sure the system stays responsive and still meets the real
time deadline of the IO thread.
On Apr 8, 2005, at 12:28 AM, Stéphane Letz wrote:
Message: 1
Date: Wed, 6 Apr 2005 12:46:12 -0700
From: Jeff Moore <email@hidden>
Subject: Re: Application with multiple IO callback on multi-processor
machines?
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes;
format=flowed
On Apr 6, 2005, at 7:54 AM, Stéphane Letz wrote:
What happens if an audio application setup several IO callback on
multi-processor machines? It seems that only one real-time thread
is actually created and all callback are probably executed in
sequence by the HAL
This is correct. There is one IO thread per device per process.
Would is make sense to have a design where the HAL is able to
create several real-time threads to be called in parallel on multi-
processor machines and correctly synchronize output buffer mixing?
This has been suggested.
It turns out that this has limited usefulness, though. Basically, the
signal processing that is done on each thread can't have any
dependencies on the processing done in the other thread since they
can be executing concurrently. Most engines out there aren't able to
meet this requirement or at the very least would require a complete
re-tooling to be able to partition their work to take advantage.
Of course, for each thread you add to the mix, you get that much more
competition at real time band. It would be very easy to paint
yourself into a corner such that the only threads getting any time
are the IO threads. Plus, as the the number of channels on the device
increases, you'd be spending more and more of the IO cycle doing the
mixing and clipping in the driver which could actually result in less
bandwidth for your application rather than more.
But I guess synchronizing mixing and clipping is what the HAL
already does when several audio applications are running together.
Then having several IO real-time threads per application is not
fundamentally different...
Generally, the conclusion has been that it is better for each engine
to figure out how to thread itself because it is the most
knowledgeable about how it works and what it needs to do, including
managing the priorities of the worker threads.
Since the ability to activate several IO callback is already there
in the CoreAudio API, then the question of how the HAL deal with
requirement of the application (assuming the application knows it
can correctly execute several completely independent threads...) on
muti-processor (soon multi-core...) machines will surely come again.
Thanks
Stephane Letz
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden