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: Jeff Moore <email@hidden>
- Date: Wed, 24 Jun 2009 11:49:13 -0700
The important thing in a real time context isn't how much CPU you use,
rather, it is that you meet the dead lines. From the sound of things,
you are failing to meet the deadlines (which you can find out about
using the overload notification). The reasons for this could be many,
but most likely you are just trying to do too much work.
There are a couple of things to keep in mind here. First, the amount
of work you do in your render proc is not the only work that gets done
for a particular IO cycle. For example, after your render proc
returns, the HAL will call down to the driver to mix the data and
prepare it for transmission to the hardware. In some cases, the driver
also needs to do some signal processing of it's own. For example, when
your MacBook is playing to the internal speakers, the driver does a
bunch of signal processing to protect the speakers from damage. All
this additional work is done after your render proc has returned but
it still has to get done before the deadline for that IO cycle.
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.
I don't know how you are measuring your CPU usage, but another thing
to keep in mind is that the clock speed of a modern Intel CPU is not
constant. Rather it's rate is determined by a bunch of factors
including thermal conditions and the load of the CPU. As such, the
amount of CPU cycles you have in a given IO cycle can vary. In other
words, you can have the exact same sequence of instructions take a
different amount of wall clock time each time the sequence executes.
The system tries pretty hard to keep this from happening, but it
happens, especially as you ramp up the load and the CPU heats up.
At any rate, you can use HALLab's IO Cycle Telemetry window (available
via the "New" menu in the "File" menu) to target your application and
see the effect of all these factors. The data HALLab collects is
collated so that you can see where the time is going in each IO cycle.
You can see how mu Youch scheudling latency there was, how much time
each IOProc took to execute and how much time the driver is spending
in the kernel trap.
For example, the built-in driver on your MacBook does it's extra
speaker protection processing only when sending data to the speakers.
This processing is turned off when using headphones/line-out. So, one
easy experiment you can do is to look for this getting reflected in
the telemetry data.
On Jun 24, 2009, at 2:50 AM, Ross Bencina wrote:
(on intel 10.5.6, dual core macbook, AUHAL)
I'm having serious problems getting stable audio from AUHAL (using
PortAudio) at high CPU loads (above 70% utilsation of one core for
doing DSP).
The symptom I have is that if my audio processing callback uses more
than about 70 - 80% of one core, the audio glitches. I can make this
happen predictably with a callback that just generates a bunch of
sine waves with the sin() function. The situation is improved with
larger i/o buffers but my minimum buffer size is already 256 samples
at 44.1k.
My impression so far (just based on how it behaves under different
loads) is that the system is limiting CoreAudio's CPU usage or not
giving it real-time priority.
I would like to diagnose the problem. I suspect it's a combination
of issues with my audio processing code (possibly cpu spikes) and
misconfiguration of CoreAudio/kernel deadlines or priorities. Or
perhaps PortAudio's AUHAL usage is the problem. Perhaps even AUHAL
is the wrong API to be using to get the most solid real-time
performance?
At the moment I'm a bit in the dark as to were to start -- but to
give you some idea, I'm prepared to re-write PortAudio/OSX if need
be to get better performance because at the moment I'm seeing worse
performance than with ASIO drivers on Windows!
My expectations are that I should be able to use at least 85% of one
core for audio processing with rock-solid audio at 44.1k with a 256
sample i/o buffer. Is this a realistic expectation for CoreAudio?
should I expected better or worse than this?
I havn't found a tool which gives detailed per-thread and per-core
CPU load information, so I havn't been able to inspect things in as
much detail as I'd like. I'd like to be able to see the kernel's
view of timing information for each timslice allocated to CoreAudio
and to see the split between CoreAudio CPU usage and my code's
usage. Any suggestions? Also is there a way (outside my app) to
monitor thread switching times and kernel scheduling events (like
missed deadlines)?
I assume that the kernel scheduler throttles the core audio callback
if it uses more than a certain amount of CPU. Is there a way to
increase the CPU allocation? Ideally I would like to assign close to
100% of one core to servicing the CoreAudio threads.
FYI I'm using PortAudio which is layered on top of AUHAL. My
settings are 44.1k with a buffer size of 256 frames (set with
kAudioDevicePropertyBufferSize) -- if I set it to 512 I can go a bit
higher with the CPU load but 256 is already much higher than I would
like.
--
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