Re: AudioFileClose() crashing on iOS after playback
Re: AudioFileClose() crashing on iOS after playback
- Subject: Re: AudioFileClose() crashing on iOS after playback
- From: Chris Santoro <email@hidden>
- Date: Sat, 2 Oct 2010 18:54:58 -0400
Thanks Brian, I certainly do need to brush up on my Core Foundation Memory Management concepts (I live in the world of plain-asm/C/C++ most of the time), but here's a concrete example of that I'm doing:
I want to start playing a file given some CFString theFilePath which I do not own. I want to use AudioFileOpenURL, so I first I create a URL.
CFURLRef audioFileURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, theFilePath, kCFURLPOSIXPathStyle, false);
Then I open the audio file, where mPlaybackFile is a member of the class that's currently doing all this.
AudioFileOpenURL (audioFileURL, kAudioFileReadPermission, 0, &mPlaybackFile);
I've got my file handle (mPlaybackFile), and now (I think) I don't need the URL I used to open the file. So I release it.
CFRelease(audioFileURL);
Then I play the file back, hit the end of the file and want to stop now, so I stop the output AU, and close the file.
AudioFileClose(mPlaybackFile);
As is, I get a bad access crash on AudioFileClose(). If I comment out the release of the URL, I don't get the crash. Was it wrong of me to assume that I didn't need that URL anymore?
Best,
Chris
On Sat, Oct 2, 2010 at 5:55 PM, Brian Willoughby
<email@hidden> wrote:
I could be misunderstanding your code, but if you keep a reference to a file handle then you should retain it. Without a retain, anything could release and free the file handle, and then it would be an invalid handle. Take care that some forms of creation and initialization result in an automatic retain, while others do not - it's up to you as the developer to understand and control this. The audio object should also retain any file handle that you use to create it, but you should be careful not to release the file handle before you hand it off to the audio object.
Brian Willoughby
Sound Consulting
On Oct 2, 2010, at 14:46, Chris Santoro wrote:
Thanks! That seems to be it. I was releasing the URL right after successfully opening the file, and getting an AudioFileID. Although, I don't understand why that would be a problem, conceptually. I would think all I'd have to do is keep a reference to the file handle (AudioFileID) around. But apparently the audio file object keeps a reference to the URL it was opened with? I wouldn't expect that to be the behavior, but I guess there's a good reason for it?
Thanks again,
Chris
On Fri, Oct 1, 2010 at 11:43 AM, Doug Wyatt <
email@hidden> wrote:
Are you overreleasing the URL that was passed to AudioFileCreateWithURL?
On Sep 30, 2010, at 22:12 , Chris Santoro wrote:
> I'm trying to do some simple file playback on the iPhone (SDK 4.1). I wrote an audio engine using RemoteIO that does recording (with input monitoring), and playback. Everything works fine except for the playback at the moment. Whenever I try to close the file that I've been playing back (for instance, when hitting the end of the file), I get an EXC_BAD_ACCESS. The audio file handle that I'm trying to close is not NULL. It's still a good file for all I know. The code is modeled after AudioPlayer in SpeakHere, and does everything the same as far as I can tell, except I'm using rIO instead of Audio Queue Services. Audio format is Linear PCM.
>
> My playback callback uses AudioFileReadBytes() and continues to read bytes from the file until it reads less than the requested number. Then it calls a Stop() function that calls AudioOutputUnitStop() and AudioFileClose(). It crashes when trying to close the file. The entire file plays back successfully before crashing on AudioFileClose().
>
> Any ideas on what could cause AudioFileClose() to crash in this scenario?
>
> Here's the stack trace if it helps. I'm stumped.
>
> #0 0x3510741c in objc_msgSend
> #1 0x35750c74 in CFRelease
> #2 0x360a5964 in AudioFileObject::~AudioFileObject
> #3 0x360a58ec in CAFAudioFile::~CAFAudioFile
> #4 0x360a57f0 in AudioFileObjectHandle::~AudioFileObjectHandle
> #5 0x360a5130 in AudioFileClose
> #6 0x000438ea in IOEngine::StopPlayback at IOEngine.mm:526
> #7 0x000449c6 in IOEngine::outputCallback at IOEngine.mm:116
_______________________________________________
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