Lists

Terms and Conditions
Lists hosted on this site
Email the Postmaster
Tips for posting to public mailing lists

Re: Edirol FA-101 and CoreAudio (Jeff Moore)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Edirol FA-101 and CoreAudio (Jeff Moore)

Subject: Re: Edirol FA-101 and CoreAudio (Jeff Moore)
From: William Stewart <email@hidden>
Date: Wed, 14 Sep 2005 10:59:45 -0700


On 14/09/2005, at 4:24 AM, Roni Music wrote:


----- 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?

Not necessarily. If the buffer list is an allocated list, then the list's pointers should remain fine. If the list's a non-allocated list (the mData pointers are NULL), then the first time you return from this call your list is now going to contain mData pointers. If you then call it again without resetting these to NULL, then you are now passing in pointers to memory you don't own!

I've seen cases where this was done - then some kind of format change deallocated those pointers, and bang!

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?

I'm speculating - but if the above were happening, once you closed down the AU, then your buffer pointers would now be disposed (because they were pointers you didn't own, but were owned by the AU). So, any attempt to use the data they pointed too would of course be bad.

I think this is what is happening - the call to New just allocates the buffer list, but doesn't allocate pointers (so the FIRST time you call AudioUnitRender with this list, these buffer pointers should be NULL) - then when you come back from AURender they will have been reset to pointers to buffers owned by the AU. So, before you call AURender again, those pointers should be set to NULL. You should also check that the mDataByteSize has been set up properly (num frames * sizeof(float) in this case) - it doesn't look like it has been to me.

Can you check this?

Doug would also be best to check this - but from what I can see there's no action to re-establish the integrity of the buffer pointers at this time.

Bill


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: 40apple.com

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 _____________________________________________________________________ ___ __

-- 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


Follow-Ups:

Re: Edirol FA-101 and CoreAudio (Jeff Moore)
From: "Roni Music" <email@hidden>


References:  
  >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: "Roni Music" <email@hidden>)
  >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: William Stewart <email@hidden>)
  >Re: Edirol FA-101 and CoreAudio (Jeff Moore) (From: "Roni Music" <email@hidden>)




Prev by Date:
Re: Edirol FA-101 and CoreAudio

Next by Date:
Re: AudioFileComponents

Previous by thread:
Re: Edirol FA-101 and CoreAudio (Jeff Moore)

Next by thread:
Re: Edirol FA-101 and CoreAudio (Jeff Moore)

Index(es):

Date
Thread