Re: need help with AUHAL audio glitching at high cpu utilisation
Re: need help with AUHAL audio glitching at high cpu utilisation
- Subject: Re: need help with AUHAL audio glitching at high cpu utilisation
- From: "Ross Bencina" <email@hidden>
- Date: Thu, 25 Jun 2009 17:34:24 +1000
Thanks for your extensive, clear and helpful response Jeff.
I didn't know about the HALLAB telemetry -- that sounds like exactly what
I'm looking for. I will check it out and report back (also thanks to Jim for
the Shark pointers -- I had looked in Shark before, but obviously not hard
enough).
Jeff Moore wrote:
The important thing in a real time context isn't how much CPU you use,
rather, it is that you meet the dead lines.
I understand that. But the deadlines impact how much CPU I can use, and what
I am trying to establish how close to 100% utilisation the deadlines allow.
For example, are the deadlines set conservatively with a 20% margin? or is
there perhaps 20% scheduling jitter?
My CPU utilisation figures are based on measured wall time within the CA
callback. I'm using gettimeofday (which I know I shouldn't but removing the
calls to gettimeofday has no impact on observed instability at high CPU load
so at least that is not the source of my problems).
I'm familiar with the real-time programming issues you've presented. The one
about variable cycle availability due to CPU thermal management is one I've
discussed with Bill before -- its concerning that the OS is unable to make
guarantees about available clock cycles for a real-time process -- I don't
really see how real-time work can be done without this -- but I realise its
a problem outside the scope of CA.
There are a couple of points I asked about which you didn't cover, and which
I'd be interested in concrete feedback on:
1. Does some part of the os place specific cycle utilisation quotas on the
CA HAL thread that would limit it such that a single core cannot be run at
full utilisation for audio processing?
2. If I do miss one deadline, will this have any impact on the scheduling of
future CA HAL callbacks? (Ie does the scheduler policy punish threads which
don't observe their deadlines?)
3. Can you give me any benchmarks as to how much CPU I should expect to be
able to use on a single core with a 256 frame buffer?
Also, is there a way for an app to access the HAL telemetry data inside the
app? It sounds like I should switch to using the OS to provide CPU load
information to my users (and also indicate the split of app/os cpu
utilisation for audio processing).
Another thing to keep in mind is that the scheduling latency of the IO
thread also counts against the amount of time you have to run in an IO
cycle. The scheduling latency is basically a function of CPU load. The IO
thread is about as high a priority thread as there is, but it still has
to compete against other real time tasks.
You seem to be suggesting that there is no way to guarantee that a CPU bound
audio application can run with high single-core utilisation. Yet this is a
function of at least one Apple product and many others.
On a multi-core system is there a way to ensure that CA gets a dedicated
core so that it doesn't have to compete with other real-time tasks?
Does CoreAudio or the kernel make any guarantees at all about maximum
scheduling jitter or how much out-of-band (ie below my audio code)
processing time will be consumed in the audio thread?
Thanks!
Ross
_______________________________________________
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