Re: Different input buffer and output buffer sizes in IOProc?
Re: Different input buffer and output buffer sizes in IOProc?
- Subject: Re: Different input buffer and output buffer sizes in IOProc?
- From: Jesper Papmehl-Dufay <email@hidden>
- Date: Tue, 26 May 2009 14:35:47 +0200
I have finally gotten hold of a M-Audio FW410, and I can reproduce the
problem easily by changing the sample rate of the device a few times
while my app is running.
If I look at the inInputData AudioBufferList that I get in my IOProc,
it looks like this:
mNumberBuffers = 1
mBuffers[0] =
mNumberChannels = 2
mDataByteSize = 4096
mData = some address
and the outOutputData AudioBufferList looks like this:
mNumberBuffers = 1
mBuffers[0] =
mNumberChannels = 10
mDataByteSize = 16384
mData = some address
When our code calculates the input buffer size in frames, it gets
4096 / (4 * 2) = 512
and the output buffer size in frames becomes 16384 / (4 * 10) = 409,6
(If outOutputData-> mBuffers[0].mNumberChannels would have been 8, the
output buffer size would be 512 frames and all would be well.)
Are we doing something wrong when calculating the buffer sizes? I'll
try to see if I can notice the problem in HALLab, but the problem
seems to exist for only a single IOProc call and then fix itself, so
I'm not sure how to reproduce it in HALLab.
Thanks,
Jesper Papmehl-Dufay
Propellerheads
12 maj 2009 kl. 20.11 skrev Jeff Moore:
The IOProc should always be seeing the same number of sample frames
in all the buffers in each AudioBufferList it is passed.
This is a function of the HAL and not the audio driver. There really
isn't any provision in the code for something like this to happen,
and I've never seen a report of it happening before now.
So I suspect there is a bug involved somewhere. It could be in your
instrumentation or it could be in the HAL. Your best bet would be to
boil this down to a simpler test case (say using HALLab for
example), and put it in a bug so we can take a look at it.
On May 12, 2009, at 4:51 AM, Jesper Papmehl-Dufay wrote:
One of our testers have reported a problem in our app where it
asserts in our IOProc due to the input buffer size being different
from the output buffer size.
(We calculate the buffer sizes by dividing inInputData-
>mBuffers[0].mDataByteSize by (sizeof(float) * inInputData-
>mBuffers[0].mNumberChannels) for the input side, and in the same
way for the output size using the outOutputData AudioBufferList
parameter to the IOProc.)
Is it really normal for a device to have different sizes for the
input and output buffers in a single IOProc call? Or should we
consider this a driver bug and handle it accordingly?
The user reports getting our assert when changing the sample rate,
so it's possible the driver is in some kind of transitional state
when this happens. The audio device used is a M-Audio FW410.
We use the HAL directly and install the IOProc using
AudioDeviceAddIOProc, if that makes any difference.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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