Re: Crash deep inside CoreAudio
Re: Crash deep inside CoreAudio
- Subject: Re: Crash deep inside CoreAudio
- From: Evan Olcott <email@hidden>
- Date: Tue, 19 Jul 2005 11:40:16 -0500
On Jul 19, 2005, at 11:09 AM, Doug Wyatt wrote: If it were happening on your machine, I'd add code to the end of the AudioConverter input callback function to read bytes from the beginning and from the end of the buffer being returned to the AudioConverter. Then you'd presumably crash in your own code and be able to debug more directly. If you didn't crash, that would say something else ...
Since it's not happening on your machine, I'd suggest scrutinizing the code in your input callback and see how it might be possible to be returning a bad buffer pointer or size. Are you filling in mDataByteSize in the AudioBuffer?
Because I'm using AudioConvertorConvertBuffer(), I don't think I *have* a callback to trap, nor do I have an mDataByteSize to fill - this is direct buffer-to-buffer with given byte size conversion:
AudioConverterConvertBuffer(fileConvertor, fileBufferDataByteSize, fileBufferData, &bufferList->mBuffers[c].mDataByteSize, bufferList->mBuffers[c].mData);
fileBufferData is the data I've read from the audio file itself, and bufferList is the set of buffers I send back from the callback (the [c] is because I do this separately for each channel). bufferList stays static throughout, so we know that's good. Since we're getting a bad *load*, I'd point the finger that the fileBufferDataByteSize or fileBufferData - but I've just been filling that stuff up just previous to the ConvertBuffer() call. Maybe something's spilling out?
Any other ideas? (Liked those, tho)...
Ev Technical Knowledge Officer Head Programmer/Designer Audiofile Engineering
|
_______________________________________________
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