Re: CoreAudio on dual-G5s
Re: CoreAudio on dual-G5s
- Subject: Re: CoreAudio on dual-G5s
- From: Jeff Moore <email@hidden>
- Date: Thu, 15 Jun 2006 16:15:29 -0700
Nope. No such bug is known to exist. I use the HAL everyday on my
dual G5 with 4GB of RAM without any issues like this.
At any rate, it sounds like you are experiencing overloads. You don't
say how you are measuring the CPU load, but CPU load isn't a good
indication of performance of a real time system anyway. Typically,
these are average loads and the problems come about at times of peak
load which can be way higher than the average load.
There are a lot of reasons why you might be seeing this. Most of them
have to do with what else is going on on the system at the time. The
most likely cause is that there's just too much stuff going on.
Another cause could be bad RAM.
Regardless, you will need to do a lot more digging into this before
we can identify the problem. The first tool to use is the IO cycle
telemetry viewer in HALLab. This allows you to snoop on what's going
on with the IO thread in other processes. The IO cycle telemetry is
good for breaking down where the time is going in the IO thread. You
can see if it's your IOProc that is taking too long or if it's some
scheduling latency, or even the driver going out to lunch.
The next tool you'll want to use is Shark's System Trace facility.
This will give you a bird's eye view on all the system activity on
the system. It will allow you to see which threads are running
instead of the IO thread, for example. It can also show you why a
given thread might be blocked or why it got pre-empted.
On Jun 15, 2006, at 4:03 PM, Robert Dotson wrote:
I'm having some strange issues recording audio on dual-G5 machines
with > 2Gb of ram. When I record audio at any rate (44kHz is a good
example) using a CoreAudio either with my own programs or
commercial apps like Sound Studio 3, the recording stutters and
drops out frequently, leaving large gaps in my waveforms, and
ruining my recordings.
When I schedule my realtime audio thread, I register a callback
with audioDeviceAddPropertyListener(). Every time the drop outs
occur, using either my software or commercial packages, I receive a
callback notifying me that my thread couldn't run in the time
allotted, which is quite strange, since the cpu load *never* goes
above 10%.
I have been able to duplicate this problem on several g5s of
various vintages, oses and configurations. When I remove enough ram
to get the machines below 2GB, the problem mysteriously disappears.
The problem is also strangely absent when I run the same programs
on less powerful machines (powerbooks, imacs, g4s, etc).
Is there a bug in core audio that only affects large memory, 64bit
machines?
--
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