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: Stéphane Letz <email@hidden>
- Date: Fri, 8 Apr 2005 09:28:09 +0200
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
_______________________________________________
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