Re: ExtAudioFileRead Crash
Re: ExtAudioFileRead Crash
- Subject: Re: ExtAudioFileRead Crash
- From: William Stewart <email@hidden>
- Date: Mon, 12 Oct 2009 17:14:11 -0700
These are certainly good things to be checking (if you know that your
buffer allocation is 64K, then I would just check that the base level
address + offset + num bytes to read, is less than base level address
+ 64 k => good place for an assertion), but I suspect that isn't the
real problem.
As we previously noted, you can't be accessing the same ext audio file
object from different threads at the same time - between your buffer
and the file is an audio converter, and it has potentially alot of
state that is NOT protected from simultaneous access. If this is being
accessed from more than one thread, it is quite likely that a buffer
is being overidden.
What is the call stack that ends in the "CrashIfClient..." - we have
that in a number of places, and knowing which one you are hitting can
tell us where you are crashing at least (potentially which buffer is
bad)
Bill
On Oct 12, 2009, at 4:47 PM, Peter Castine wrote:
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
_______________________________________________
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