Re: More Glitches
Re: More Glitches
- Subject: Re: More Glitches
- From: Jeremy Sagan <email@hidden>
- Date: Mon, 14 Feb 2005 21:40:43 -0500
Jeff,
I am not too familiar with the OS so I could be way off here but I also
have some questions regarding glitches. I do get overload notifications
though and they seem to happen way more if GDB is running.
Is it possible to get a glitch solely because of VM from a different
thread? If another thread is taking a lot of page faults all in a row
would that cause the I/O procedure to be starved? If the answer to the
first two is yes, then shouldn't there be a mechanism in the OS that
causes the audio I/O procedures to get called immediately after the
first and between each page fault?
Jeremy
On Feb 14, 2005, at 6:46 PM, Jeff Moore wrote:
Glitches that don't correspond to over loads can be caused by lots of
things. The usual cause is supply chain issues, but there have been a
handful that are hardware/driver related.
It's tough to say anything more without knowing more about the
situation.
On Feb 14, 2005, at 3:39 PM, Ethan Funk wrote:
So this implies that the HAL is getting all the data from me that it
needs and getting it on time to keep the device well feed, correct?
What does that leave for a source of a glitch? Something driver
related on the interface between the HAL and the actual device? The
source audio buffers that my IO cycle pulls from are huge, so I don't
thinks the glitches are coming from the feeder threads - I am
showing a typical feeder lead of between 10 and 15 seconds at all
times.
Thanks for the help
Ethan...
On Feb 14, 2005, at 15:35, Jeff Moore wrote:
The HAL only sends overload notifications when it detects them as
part of the normal execution of the house keeping code at the end of
each IO cycle. The HAL doesn't have any magical insight, so if you
are getting glitches without a corresponding overload, it would
imply that the glitching isn't related to the time being spent on
the IO thread.
On Feb 14, 2005, at 12:58 PM, Ethan Funk wrote:
In my eternal hunt for the source of audio glitching, I have added
the following code to my project to I can get a message on each HAL
output processor overload event. However, I'm not getting any
messages, even through I hear glitches. Am I doing something wrong
in setting up notification or is it possible that the glitches are
due to something else?
Here is my code for the callback: msg is a Boolean I set to true
for debugging
OSStatus HALOverloadListener(AudioDeviceID inDevice, UInt32
inChannel, Boolean isInput, AudioDevicePropertyID inPropertyID,
void *inRefCon)
{
Distributor *output = (Distributor *)inRefCon;
if(msg){
output_map_ptr dp;
string dataStr = "unknown";
// find the output in the output distributer list
pthread_mutex_lock( &oMutex );
for (dp=outputMap.begin(); dp!=outputMap.end(); dp++){
if(&((*dp).second) == output)
dataStr = (*dp).first;
}
pthread_mutex_unlock( &oMutex );
// print message
fprintf(stdout, " MESSAGE: Processor Overload on %s output,
bus #%ld.\n", dataStr.c_str(), inChannel);
fprintf(stdout, "ae>");
fflush(stdout);
}
return noErr;
}
Then I register the call back just before AU Initialization deep in
my audio setup procedure:
// set up notification of processor overload
err = AudioDeviceAddPropertyListener(devID, 0, FALSE,
kAudioDeviceProcessorOverload, HALOverloadListener, this);
if (err)
return false;
// initialize the HALoutput AU
err = AudioUnitInitialize(outHALUnit);
if (err)
return false;
There is NO error when I add the property listener. Any insight
would be appreciated!
Ethan...
--
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:
email@hidden
This email sent to email@hidden
_______________________________________________
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