Re: ExtAudioFileRead Crash
Re: ExtAudioFileRead Crash
- Subject: Re: ExtAudioFileRead Crash
- From: William Stewart <email@hidden>
- Date: Mon, 12 Oct 2009 11:35:45 -0700
On Oct 12, 2009, at 9:58 AM, Hendrik Schreiber wrote:
On 12-Oct-2009, at 9:50, Hendrik Schreiber wrote:
I think I've started seeing this one too, when handing it an ABL
that didn't fit exactly.
E.g. at the end of an audio file, the buffer would be shorter than
the number of frames I attempt to read, knowing that the file is
actually shorter than the number of frames I requested.
If this were the problem, wouldn't it be happening on Leopard just
as much on Snow Leopard?
No, because they are not the same...
In any case, the first time I saw that
CrashIfClientProvidedBogusAudioBufferList frame was on Snow Leopard
and I have not seen it on Leopard yet.
This is a new call in SnowLeopard. We added this in a couple of places
because, well clients are passing us bogus buffers and we write over
memory we shouldn't. (In Leopard, you then get some random memory
scribble causing havoc, or not). The intention of the call is to read
from both ends of the buffer you provide, and if we crash, its because
the allocated memory is smaller than the data size you say it is.
So, that explains the difference, but you seem to have some
discrepancies between what you think you are doing and what you do do
(which this crash would point out).
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.
Bill
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.
Anyway, here is the code. The AudioBufferList is set up as a single
buffer, with buffer size always exactly matching the requested
number of frames.
I'm sure you did, but I'd double-check that.
-hendrik
----
static OSStatus
SNDFileRead(
tSFParam* ioParams,
tSfBufferChunk* ioChunk)
{
OSStatus status = noErr;
ExtAudioFileRef af = ioParams->sf;
tSfBuffer* buffer = ioParams->buffer;
UInt32 numFrames = ioChunk->chunkFrames;
AudioBufferList bufList;
// Set up an AudioBufferList
bufList.mNumberBuffers = 1;
bufList.mBuffers[0].mData = buffer->data + ioChunk-
>bufferPos;
bufList.mBuffers[0].mDataByteSize = numFrames * ioParams-
>info.clientStream.mBytesPerFrame;
bufList.mBuffers[0].mNumberChannels = ioParams-
>info.clientStream.mChannelsPerFrame;
status = ExtAudioFileRead(af, &numFrames, &bufList);
if (status != noErr) goto punt;
ioChunk->chunkFrames = numFrames;
ioParams->info.clientPos += numFrames;
punt:
return status;
}
----
_______________________________________________
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