Re: Source debugging into coreaudio
Re: Source debugging into coreaudio
- Subject: Re: Source debugging into coreaudio
- From: Jeff Moore <email@hidden>
- Date: Fri, 30 Oct 2009 11:00:39 -0700
Well then. I guess you were right to suspect the driver. I'll be
curious to see what the ultimate cause of this problem turns out to be.
On Oct 29, 2009, at 10:44 PM, Chuck Carlson wrote:
On Thu, Oct 29, 2009 at 12:07 PM, Jeff Moore <email@hidden> wrote:
I ran your code on a couple of machines (a MacPro and MacBook Pro to
be specific) running SnowLeopard in both 32 bit and 64 bit forms and
never saw any crashes.
Thanks, and this result is expected. The crash happens only on the
second run when the device is our custom usbaudio device. Does not
happen on a generic AppleUSBAudio device.
The first run can be using any device, including built audio device.
The only way for you to duplicate this crash is to run with our
device and our usbaudio kext that supports it. This kext was based
on the generic AppleUSBAudio kext and modified to work with our
device.
Perhaps there is something installed on your machine that is
corrupting the heap. I recall you mentioning previously that you had
a USB audio device installed. Does it have a HAL plug-in perchance?
Is there anything else installed on your system that does?
No HAL plugin used.
I suspect our driver is providing some information to HAL which
causes it to crash.
But, linking to the carbon framework fixes the problem. Since it's
so difficult to debug and I'm confident our user space application
is not the problem I'm willing to leave this for now until a easier
situation to debug arises.
--Chuck
--
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