Re: Edirol FA-101 and CoreAudio (Jeff Moore)
Re: Edirol FA-101 and CoreAudio (Jeff Moore)
- Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
- From: "Roni Music" <email@hidden>
- Date: Wed, 14 Sep 2005 13:24:48 +0200
----- Original Message -----
From: "William Stewart" <email@hidden>
To: "Roni Music" <email@hidden>
Cc: <email@hidden>
Sent: Tuesday, September 13, 2005 9:10 PM
Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
>
> On 13/09/2005, at 5:28 AM, Roni Music wrote:
>
> >
> >
> >> Subject: Re: Edirol FA-101 and CoreAudio
> >>
> >> If you look closely, the crash is happening on the IO thread. From
> >> the back trace, I'd guess that it is happennig inside an
> >> AudioConverter or the the Render method of an AudioUnit somewhere.
> >>
> >
> > It happens when my input callback calls AudioUnitRender()
> > (exactly the same as in the "afrecord" example or TN 2091)
>
> Are you preparing the Audio Buffer List you pass to AudioUnitRender
> *every* time?
No, I'm doing the same as in the "afrecord" example,
using the CABufferList::New() when seting up,
destroying it as the last thing.
As I see it, that should always be valid, or?
Is there anything else I should do?
> You could have a problem where you start off with a
> NULL buffer list, you get back a buffer list with pointers, something
> about the device changes
Do you mean that something about the device could change at the same time
as it's closing down and that I need to have a property listener checking that?
Rolf
> and those pointers (which weren't yours to
> begin with) are now changed and you crash.
>
> I've seen crashes like this in the past with similar symptoms.
>
> Bill
>
> >
> >
> >>
> >> My guess is that the reason for the crash is that your app has
> >> encountered a NULL buffer where it didn't expect to find one and
> >> passed it to the converter or AU in question.
> >>
> >
> > All memory buffers are valid at this point.
> > They are deleted as the last thing in my destructor, so they are
> > valid,
> > unless the following calls returns before they have performed what
> > they are supposed to do.
> >
> > AudioOutputUnitStop(mInputUnit);
> > AudioUnitUninitialize(mInputUnit);
> > CloseComponent(mInputUnit);
> >
> > At this point the AURenderCallback should never ever be called
> > again, right?
> > So now it should be safe to destroy all memory.
> > The crash happens only when closing down the recording stuff, else
> > it works fine.
> >
> > The custommer also reports that everything worked OK untill he
> > upgraded to Tiger
> > I have never experienced the problem myself on any version of OS X
> >
> > My software is built with XCode 2.1 using gcc 3.3 if that matters
> >
> > Rolf / Roni Music
> >
> >
> >
> >>
> >> On Sep 12, 2005, at 2:07 AM, Roni Music wrote:
> >>
> >>
> >>> I have a crasch that only occurs with the Edirol FA-101 FireWire
> >>> interface and Tiger for one of my custommers.
> >>>
> >>
> >>
> >> --
> >>
> >> Jeff Moore
> >> Core Audio
> >> Apple
> >>
> >>
> >>
> >
> >
> > Thread 4 Crashed:
> >
> > 0 <<00000000>> 0xffff8b2c __memcpy + 908 (cpu_capabilities.h:189)
> >
> > 1 ...pple.audio.units.Components 0x9a2efa08
> > dyld_stub__keymgr_get_and_lock_processwide_ptr + 33288
> >
> > 2 ...pple.audio.units.Components 0x9a2ef974
> > dyld_stub__keymgr_get_and_lock_processwide_ptr + 33140
> >
> > 3 ...pple.audio.units.Components 0x9a224d10 DefaultOutputAUEntry +
> > 29112
> >
> > 4 ...pple.audio.units.Components 0x9a2210e4 DefaultOutputAUEntry +
> > 13708
> >
> > 5 ...pple.audio.units.Components 0x9a220b3c DefaultOutputAUEntry +
> > 12260
> >
> > 6 ...pple.audio.units.Components 0x9a2f15a4
> > dyld_stub__keymgr_get_and_lock_processwide_ptr + 40356
> >
> > 7 ...ple.CoreServices.CarbonCore 0x90b51ff0 CallComponent + 260
> >
> > 8 ...apple.audio.units.AudioUnit 0x94179cc4 AudioUnitRender + 56
> >
> > 9 com.ronimusic.audiocompanion 0x00030b9c
> > CMyAudioFileRecorder::InputProc(void*, unsigned long*,
> > AudioTimeStamp const*, unsigned long, unsigned long,
> > AudioBufferList*) + 204 (CMyAudioFileRecorder.cpp:547)
> >
> > 10 ...pple.audio.units.Components 0x9a2245d0 DefaultOutputAUEntry +
> > 27256
> >
> > 11 com.apple.audio.CoreAudio 0x913b74e0 IOA_Device::CallIOProcs
> > (AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp
> > const&) + 376
> >
> > 12 com.apple.audio.CoreAudio 0x913b71f4 HP_IOThread::PerformIO
> > (AudioTimeStamp const&) + 532
> >
> > 13 com.apple.audio.CoreAudio 0x913b5230 HP_IOThread::WorkLoop() + 1156
> >
> > 14 com.apple.audio.CoreAudio 0x913b4d98 HP_IOThread::ThreadEntry
> > (HP_IOThread*) + 16
> >
> > 15 com.apple.audio.CoreAudio 0x913a5f7c CAPThread::Entry
> > (CAPThread*) + 96
> >
> > 16 libSystem.B.dylib 0x9002c3d4 _pthread_body + 96
> >
> > _______________________________________________
> > 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
> >
>
> --
> mailto:email@hidden
> tel: +1 408 974 4056
> ________________________________________________________________________
> __
> "Much human ingenuity has gone into finding the ultimate Before.
> The current state of knowledge can be summarized thus:
> In the beginning, there was nothing, which exploded" - Terry Pratchett
> ________________________________________________________________________
> __
>
>
_______________________________________________
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