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 16:32:54 -0400
Bill,
OK, so you cleared up my question that
ExtAudioFileGetProperty(kExtAudioFileProperty_FileLengthFrames) will
return in terms of the kExtAudioFileProperty_ClientDataFormat that's
specified. However:
In one run:
2009-03-11 16:25:57.009 AFTest[1850:4813] client data format
2ch-44100.00hz-32bit-'mcpl' floating-point little-endian packed
2009-03-11 16:25:57.009 AFTest[1850:4813] file data format
2ch-44100.00hz-0bit-' caa'
2009-03-11 16:25:57.010 AFTest[1850:4813] got frame count 177743235
instead of 11106972
In another run (different file):
2009-03-11 16:31:00.002 AFTest[1884:48d7] client data format
2ch-44100.00hz-32bit-'mcpl' floating-point little-endian packed
2009-03-11 16:31:00.002 AFTest[1884:48d7] file data format
2ch-44100.00hz-0bit-' caa'
2009-03-11 16:31:00.002 AFTest[1884:48d7] got frame count 131756937
instead of 8232828
Both sample rates are exactly the same, and the discrepancy is
incredibly large. In both cases, though, it appears that the
erroneous value is very slightly over 16x the correct value.
Thoughts?
Chris
On Mar 11, 2009, at 4:16 PM, William Stewart wrote:
yes
ExtAudioFile is going to generally give you information in regards
to the client format that you are using to talk to the file.
If you want to know information about the file itself, you can (and
should) go directly to the underlying audio file object as a general
rule
So, if your client format is at a different sample rate than the
file, then your idea in the terms of that format, of the length of
the file (that is, the number of samples that you will read in your
client format) is different than the actual length of the file (the
number of samples that are in the file)
So, I think this is the discrepancy that you are seeing
Bill
On Mar 11, 2009, at 8:24 AM, Christopher Liscio wrote:
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:
@apple.com
This email sent to email@hidden
_______________________________________________
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