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: Thu, 14 Sep 2006 11:38:07 -0600
On 13-Sep-06, at 7:34 PM, William Stewart wrote:
On 13/09/2006, at 12:07 PM, Doug Zwick wrote:
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.
You don't need to do this yourself - the callback tells you how
many frames are available when it calls you - you should use that
number.
I understand that, however, given the two circumstances under which
the -10863 error code can be returned, one of these two assumptions
must be wrong:
- the number of frames actually available matches the callback
argument
- the AUHAL has been started because my input callback has been
called
I'm looking for a way to test the first assumption in diagnostic
code, to find out why I get back -10863. However, this is to aid in
debugging my issue with sample rate (see below). Perhaps when I
understand that issue better this will not be important.
Given that these are the only two cases where AudioUnitRender can
return -10863, I'm looking at the sample rate issue again.
The sample rate is part of the 2. case - AUHAL doesn't allow rate
conversion for input - so the sample rates between your side and
the device side must match.
I think you missed the gist of my question: I'm not looking for rate
conversion here, I'm looking to set the input device to record at a
device-supported sample rate. I am testing with two audio devices: a
USB mic (supports input at 8000, 11025, 22050, 44100 and 48000 Hz
according to Audio MIDI Setup and HALLab), and an iSight (48000 Hz
only). I would expect that trying to set a sample rate of 8000 Hz in
the set property call for SampleFormat would work properly for the
USB mic (as the device supports that rate), but return an error code
for the iSight. I always get a zero error code back from the set
property call, and it fails in both cases when AudioUnitRender is
called. Is setting the mSampleRate field of the
kAudioUnitProperty_StreamFormat property the correct way to select a
supported device sample rate that is not set as the current nominal
sample rate? If I change the nominal rate of the USB mic to 8000 Hz
via Audio MIDI Setup, setting a rate of 8000 Hz via the SampleFormat
property for the USB mic works as I expect. If setting the
mSampleRate field of the StreamFormat property works as I thought it
did, it would set the device to record at the specified rate for
device-supported sample rates, and return an error code for
unsupported sample rates. Since this doesn't happen, I must be
missing something. Is this the proper way to select an alternate,
supported sample rate? Perhaps it is the meaning of "nominal sample
rate" I don't understand, I assume it to mean the preferred sample
rate. Is it mandatory to set the nominal sample rate for the device
before trying to set the format of the audio unit (I'm trying to
avoid making any persistent changes to the audio device state that
I'd have to set back later)?
I will want to look at rate conversion at some point. My
understanding is that this must be done using an AUGraph with a
converter unit connected to the AUHAL. I was going to model my code
on the use of the varispeed unit on the output side of the
ComplexPlayThrough example. If this starts getting complex, I can
fall back on the existing resampling code in the calling app (the old
SoundManager-based code worked this way), and leave resampling for a
another day.
_______________________________________________
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