Re: HAL IO thread priority and glitching
Re: HAL IO thread priority and glitching
- Subject: Re: HAL IO thread priority and glitching
- From: Jeff Moore <email@hidden>
- Date: Wed, 18 Sep 2013 18:29:00 -0700
Without any actual evidence, it is nearly impossible to say what is happening. Please file a bug.
That said, I know you say you aren't doing anything that blocks inside your IOProc. But there are lots of things in the system that you can call that will block. The most common problem I've seen is an making ObjC method invocations on the IO thread. ObjC is a wonderful application level tool, but it is most definitely not real time safe. There are code paths in the method dispatcher that block for unbounded amounts of time. So, we recommend that your app stay away from making any ObjC calls inside the IOProc. Note that this goes for using most CoreFoundation objects as well given that a good many of them are directly implemented in ObjC.
So, I encourage you to do a through scrub to ensure that you are not doing any of that.
Finally, while the IO thread is a real time thread, it can still be held off by other high priority work on the system. Off the top of my head, the most likely scenario here is that there is some kind of VM fault happening. Note that you can use a System Trace in Instruments to track down what is going on on the IO thread.
—
Jeff Moore Core Audio Apple
On Sep 18, 2013, at 4:43 PM, Stephen F. Booth < email@hidden> wrote: I recently encountered a predictable, reproducible glitch while working on some audio code. In a simple Cocoa application any time I would pull down the Help menu for the first time (or occasionally open NSOpenPanel for the first time) I would receive a kAudioDeviceProcessorOverload notification accompanied by an audible glitch. Even though I perform no blocking operations in my IOProc I can't seem to eliminate the issue; in fact, simply returning noErr still resulted in the overload. I was able to reduce this down to a test case using an AUGraph consisting of two AUs, an AudioFilePlayer unit driving a HALOutput unit in a boilerplate Xcode Cocoa non-NSDocument application. I've posted the code on github at https://gist.github.com/sbooth/6617154
After launching the app and opening a file, pulling down the Help menu (the first time only) results in a glitch and kAudioDeviceProcessorOverload notification nearly 100% of the time. I know that the HAL IO thread is a real time, high priority thread so I was surprised to have this happen. Is there a bug somewhere in my code that I can't see? I've tried everything I can think of to remedy the situation to no avail. Since the bug happens in my code as well as Apple's I'm stumped.
I should mention I'm running 10.8.5 on a MacBookPro8,2.
|
_______________________________________________
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