Re: Multiple ExtAudioFileRefs pointing to the same file
Re: Multiple ExtAudioFileRefs pointing to the same file
- Subject: Re: Multiple ExtAudioFileRefs pointing to the same file
- From: Christopher Liscio <email@hidden>
- Date: Wed, 11 Mar 2009 11:24:48 -0400
Having this case narrowed down to a NSTimer that spawns off threads
rapidly to re-open the file and query its frame count has allowed me
to noodle around with the CoreAudio calls a little bit and see how
behavior changes.
On Mar 10, 2009, at 10:02 PM, Christopher Liscio wrote:
Of course, the CoreAudio calls are wrapped in some Objective-C, but
there are really only two routines in SMUGExtendedAudioFile to check
out here:
- (id)initForPlaybackWithFilename:(NSString*)filename
- (SInt64)frameCount
I didn't realize earlier in my original problem statement that there
is an extra call in between ExtAudioFileOpenURL and
ExtAudioFileGetProperty(kExtAudioFileProperty_FileLengthFrames). That
is, of course,
ExtAudioFileSetProperty(kExtAudioFileProperty_ClientDataFormat).
When opening the audio file, I set the client data format right away,
so that the frame count would be in terms of the client's sample
rate. This, of course, might be a poor assumption (please, enlighten
me!), but I digress...
Anyway, if I remove the call to setting the ClientDataFormat, this
problem appears to go away (or become extremely less frequent). If
you comment out the call to setClientDataFormatForPlayback in
SMUGExtendedAudioFile.m, you'll probably notice the same change in
behavior.
More food for thought, I guess...
Cheers,
Chris Liscio
http://SuperMegaUltraGroovy.com
Acoustic measurement software for Mac OS X -- http://www.FuzzMeasure.com
_______________________________________________
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