Re: ExtAudioFileRead Crash
Re: ExtAudioFileRead Crash
- Subject: Re: ExtAudioFileRead Crash
- From: Peter Castine <email@hidden>
- Date: Tue, 13 Oct 2009 01:47:24 +0200
Thanks for your input.
On 12-Oct-2009, at 20:35, William Stewart wrote:
With the code below, your data byte size and num frames should be
matched - so, you would have to ensure that the pointer that is
pointed to by (buffer->data + ioChunk->bufferPos) is large enough to
hold that many bytes.
To be really safe, I would have a variable in ioParams that keeps
the allocated byte size of buffer->data, and does some bounds
checking against that. The assumption that is not tested below is
that buffer->data is always large enough.
buffer->data is always 64kB (sorry for not including all the typedefs
I'm using, hopefully the struct member names are moderately
descriptive). ExtAudioFileRead() is being asked for at most 16384/
mBytesPerFrame frames at a time. So the question is what ioChunk-
>clientPos is doing.
Instead of using a simple ring buffer for buffer->data (which
ExtAudioFile reads into and the playback code reads out of), there is
a more complex situation where the buffer is divided into variable-
sized "chunks", with the read size being tweaked to make sure
ExtAudioReadFile() is comfortably ahead of what the playback code
wants to access. (The thread priority is also tweaked depending on how
far ahead we are withExtAudioReadFile). And there is a lot of bounds
checking. It's not my code and it's fairly hairy, so I could be
misunderstanding something in there. The code assigning values to
ioChunk->clientPos looks solid, but I will go through it again (1:00
am is probably not the best time, though).
As a ham-fisted way of checking what's happening close to the crash, I
temporarily added the following immediately before the call to
ExtAudioReadFile()
----
NSLog(@"SNDFileRead calls ExtAudioFileRead for %s, numFrames = %d,
mDataByteSize = %d; buffer->data %p, bufferPos %d",
ioParams->fName, numFrames, bufList.mBuffers[0].mDataByteSize,
buffer->data, ioChunk->bufferPos);
----
Here on Leopard the console output all looks reasonable. I do get a
read of 2048 frames (16384 mDataByeSize) with ioChunk->bufferPos at
49152, which is reading to the absolute end of the 65536 byte buffer.
But not past the end.
I'll have to wait to check this on Snow Leopard.
On 12-Oct-2009, at 9:50, Hendrik Schreiber wrote:
Also, the soundfiles we're using are typically several minutes
long. The scenario you describe will crash when you get to the last
block of the soundfile. So we should get a few minutes of playback,
then crash. However, the behavior we are seeing is: hit-the-play-
button-BAM!
OK - that doesn't fit. I just tried to help.
And I appreciate that.
I still have a bad feeling about threading issues and am looking into
that.
Thanks again
-- Peter
_______________________________________________
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