On Jul 19, 2005, at 12:43 PM, Doug Wyatt wrote: OK, so I'd triple-check fileBufferDataByteSize and bufferList->mBuffers[c].mDataByteSize.
If fileBufferDataByteSize is too large, of course we'll read past the end and crash.
If bufferList->mBuffers[c].mDataByteSize (on entry) translates into more frames than fileBufferDataByteSize, we *should* be stopping, but if not, then the converter would then keep trying to convert and crash.
The next thing I'd try is logging fileBufferDataByteSize and fileBufferData before each call. Then when it crashes -- how does r3 relate? Is it inside the last fileBufferData, a little past the end, or somewhere completely different?
It'd also be interesting to see the output of: CAShow(fileConvertor);
-- is this a simple PCM-to-PCM converter with no rate conversion or de/interleaving, or is it more complex?
OK, I will scrutinize to death, and maybe even try some logging from that user's machine and find out what's triggering it. Something must be reading strangely, but that it's *random* (or apparently so) is what makes it rather bizarre.
The convertor is indeed a PCM-to-PCM convertor, no rate conversion, and no de/interleaving. Basically it's a bit depth convertor (and sometimes does format conversion, like uLaw to float, but that's rare).
Thanks for the tips and I'll get back to you at some point.
Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering
|