Re: More Glitches
Re: More Glitches
- Subject: Re: More Glitches
- From: Jeff Moore <email@hidden>
- Date: Tue, 15 Feb 2005 12:41:47 -0800
Note that the printf family of functions both allocates memory and
writes to a file descriptor (even sprintf does!) and so is just as
likely as anything else to cause the IO thread to block unnecessarily.
It's not a big deal for general testing, but it really gets in the way
if you are trying to test things when running on the edge of the
performance envelope.
I either use the telemetry functions of HALLab or set up my logging
code to write it's info into a pre-allocated block of memory that gets
flushed from outside of the IO thread.
On Feb 15, 2005, at 12:20 PM, Ethan Funk wrote:
I became aware of the debuger halting all threads in the app, so I
have been debuging with printf statments and such. I guess I'll take
a look at Shark and see what I can learn.
Thanks,
Ethan...
On Feb 15, 2005, at 12:36, Jeff Moore wrote:
The VM Pager is one of the few threads that are actually higher
priority than a time constraint thread like what the HAL uses for IO
threads. So, if you have another thread that is page faulting, it
can and will interfere with the performance of the IO thread,
usually by pre-empting it or causing extra latency when scheduling
it.
Shark will show you in excruciating detail when this happens, as
will latency traces.
Also note that when you debug an app with gdb, you are stopping all
the threads in the app every time you hit a break point or otherwise
cause gdb to halt the app. Consequently, you can expect to see many
more overloads than usual.
On Feb 14, 2005, at 6:40 PM, Jeremy Sagan wrote:
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:
@verizon.net
This email sent to email@hidden
--
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:
40redmountainradio.com
This email sent to email@hidden
--
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