Re: Dropped Buffers from mouse-menu tracking
Re: Dropped Buffers from mouse-menu tracking
- Subject: Re: Dropped Buffers from mouse-menu tracking
- From: William Bates <email@hidden>
- Date: Fri, 27 Apr 2012 09:45:59 -0500
Ross:
(1) Pre-10.6
It's in a comment in "AudioHardware.h" header. Just search for "10.6":
@constant kAudioHardwarePropertyRunLoop
The CFRunLoopRef the HAL is currently attaching all of it's [sic] system notification handlers to. In 10.6 and later, the HAL will use the process's run loop (as defined by CFRunLoopGetMain()) for this task. Whereas in previous releases, the HAL created and managed its own thread for the task. Clients can set this property to tell the HAL to use a thread of the client's choosing. If the value for this property is set to NULL, the HAL will return to it's pre-10.6 behavior of creating and managing it's own thread for notifications. The caller is responsible for releasing the returned CFObject.
(2) Summary of my experience with this: (1) it definitely improves real-time performance to get the HAL off the main run loop. (2) Nothing else seems to make much difference. (3) the thread scheduler slowly penalizes the HAL thread, causing degradation over time. This last is what bothers me.
(3) I'd like to understand what's going on here, not just find something that works, What's the point of having a 3 GHz, 8-core machine if it can't keep up with a microphone? I think the Amiga circa 1982 could do this. Our singers certainly notice the glitches and I'm tired of them rolling their eyes at the machine...
_______________________________________________
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