Re: AudioFileClose() crashing on iOS after playback
Re: AudioFileClose() crashing on iOS after playback
- Subject: Re: AudioFileClose() crashing on iOS after playback
- From: Kyle Sluder <email@hidden>
- Date: Sun, 3 Oct 2010 22:46:29 -0700
On Sun, Oct 3, 2010 at 9:25 PM, Brian Willoughby <email@hidden> wrote:
> Not really. The audio file object retains the audio file id because it
> needs it, and releases it during close. However, there is nothing wrong
> with your code retaining the same audio file id for the duration of time
> that it needs it, so long as it calls release. This is always the case
> unless the documentation states otherwise. In other words, if two objects
> need a reference for some extended period of time, then both should retain
> it, and then the id will not go away until both are done with it.
The Core Foundation memory management rules are explicitly very simple:
1. If the function name contains "Create" or "Copy" you get back an
owning reference and are responsible for releasing that reference.
2. If the function does not follow rule 1, you get a non-owning
reference and must retain the reference if you want to hang onto it
for a while.
http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html
If AudioFile doesn't follow these rules, that's fine. Other parts of
the system don't follow that rule either, especially parts that
predate CF.
Looking at the documentation for AudioFileCreate, I guess it's not
possible for the AudioFile API to follow CF conventions. I also don't
see anything indicating that AudioFileID is a subtype of CFType, so
CFRetain on an AudioFileID probably wouldn't work.
Bleh. My fault for assuming that AudioFileIDs were CF objects.
--Kyle Sluder
_______________________________________________
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