Re: Setting Input Sample Format and Rate
Re: Setting Input Sample Format and Rate
- Subject: Re: Setting Input Sample Format and Rate
- From: Doug Zwick <email@hidden>
- Date: Wed, 13 Sep 2006 13:07:00 -0600
On 13-Sep-06, at 12:00 PM, William Stewart wrote:
On 13/09/2006, at 10:35 AM, Doug Zwick wrote:
I'm converting some old Sound Manager input code to use CoreAudio,
using TN 2091 as a guide, and have had some odd issues. TN 2091
suggests that AUHAL will automatically convert the data format as
long as it is linear PCM. I have tried to set the input format to
16-bit signed integer, non-interleaved, packed, native endian, and
the set property call (kAudioUnitProperty_StreamFormat) succeeds
but calls to AudioUnitRender return -10863
(kAudioUnitErr_CannotDoInCurrentContext).
Have you started the AUHAL unit? If you haven't, its got no data to
give you.
Are you asking it for the same number of sample frames in the
render call as it told you it had in the callback? It doesn't
provide more or less data than what it has.
These are the two circumstances where this error arises.
Thanks for the quick reply. I believe that the AUHAL has been started
-- I call AudioOutputUnitStart on the AUHAL (return code is zero),
and I get my input callback called, so I think it has started
correctly. I found a bug in my callback -- I was double-checking the
frame count given to the callback against the buffer size (to ensure
it fit), but the code assumed 4 bytes per sample, and overrode the
input frame count thinking it would overrun the buffer. Fixing that
glitch solves the problem with SInt16 data. Thanks. It is also good
to know that I cannot request fewer frames than are available, I'll
change the buffer overrun check so it doesn't try to do that.
Given that these are the only two cases where AudioUnitRender can
return -10863, I'm looking at the sample rate issue again. The flags,
timestamp, bus number and frame count are all being passed through
verbatim, and the frame count corresponds with the value I got back
for kAudioDevicePropertyBufferFrameSize to size my input buffer, so I
expect that that is the correct value. Could the frame count vary due
to the resampling going on? If so, and if that is the reason the
audio unit has a different number of samples available than what is
requested, how would I determine what the actual number of samples
available is? I would expect CoreAudio to provide the correct value
through the input parameter, though. Is there a way I can determine
the number available for diagnostic purposes (e.g. print a message if
it doesn't match the frame count callback parameter)? I tried
changing the rate I'm requesting to 22050, and the device rate (using
Audio MIDI Setup) to 44100 so that there would be an exact integer
ratio of the sample rates to try and eliminate this as a possibility,
but it still returned -10863.
Is setting the StreamFormat property the right way to switch the
device to one of its other supported sampling rates? Also, the iSight
mic doesn't support any rate other than 48000 Hz, yet I do not get an
error trying to set its sample rate via the StreamFormat property
(and get a -10863 back from AudioUnitRender). I don't think I really
understand what setting the StreamFormat property is actually doing
here, WRT sample rate.
_______________________________________________
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