Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
- Subject: Re: ExtAudioFileRead fails after reaching EOF, despite new seek position
- From: Christopher Liscio <email@hidden>
- Date: Wed, 21 May 2008 15:55:43 -0400
On May 19, 2008, at 8:13 PM, Christopher Liscio wrote:
From the sounds of things, it's probably just me, and I have more
debugging to do. If I can come up with a tiny sample that
reproduces this behavior I'll be sure to update the thread with it.
I have a feeling I'll be slapping my forehead once I get to the
bottom of this... :P
And here I am, forehead firmly planted in my palm...
Unlike the CAAudioFileReader class' implementation, I did not get a
'modifiable' copy of the AudioBufferList struct to pass into the
ExtAudioFileRead() routine. Hence, my buffers were getting their
mDataByteSize members set to 0 when the EOF was reached.
Thus, subsequent calls to ExtAudioFileRead() were being made with 0-
length AudioBufferLists. Well, that explains the bad parameters... :/
The _really_ odd thing is that when I encountered this problem the
first time, I actually managed to 'correct' this behavior using the
seek(0) then seek(position) pattern.
I dug up an old revision of TapeDeck and tried removing the seek(0)
and still notice things get 'stuck', though ExtAudioFileRead() is no
longer reporting an error. However, I must clarify what 'stuck' means:
I hit 'play' in TapeDeck:
Seek(0) -> reads 512 frames
Seek(512) -> reads 512 frames
...
Seek(363520) -> reads 512 frames
Seek(364032) -> reads 448 frames
Seek(364480) -> reads 0 frames (EOF)
I hit 'rewind' in TapeDeck:
Seek(363328) -> reads 0 frames (EOF)
[At this point, the tape would appear to be 'stuck' and one cannot
rewind the tape.]
I instead use the mouse cursor in TapeDeck to seek back further than
the 1152 frames away from the EOF:
Seek(323463) -> reads 512 frames
Seek(323975) -> reads 512 frames
...
Seek(361351) -> reads 512 frames
Seek(361863) -> reads 505 frames
Seek(362368) -> reads 0 frames (EOF)
I hit 'rewind' in TapeDeck:
Seek(361216) -> reads 512 frames
...
[All is well - the tape no longer appears 'stuck'.]
So something strange is going on. Upon reading all the way to the EOF
the first time, it appears that ExtAudioFile gave me more samples than
the second time. 2112 samples to be exact.
Interestingly enough, that's exactly how many samples of priming the
AudioConverter is set up for. Coincidence? Probably not.
Would I be off-base by suggesting this would be a bug in
ExtAudioFile? I understand how there should be 2112 samples more than
the actual number of samples contained in an AAC audio file, but I
would also expect the number of samples accessible via
ExtAudioFileSeek() and ExtAudioFileRead() to be consistent as long as
the file remains open.
Thanks,
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