Re: HALOutputUnit (Pt 2)
Re: HALOutputUnit (Pt 2)
- Subject: Re: HALOutputUnit (Pt 2)
- From: Bob Stuller <email@hidden>
- Date: Tue, 24 Feb 2004 10:20:57 -0500
Aaron, Greetings!
At 7:13 PM -0800 2/23/04, Aaron Eppolito wrote:
Meanwhile, I am now getting a
'kAudioUnitErr_CannotDoInCurrentContext' error from AudioUnitRender
that stubbornly persists even when I stop with setting
BufferFrameSize or modifying the best-match format. I am asking
for the same number of frames my callbacks gets as a parameter.
What other causes for this error are possibilities?
This sounds like the same problem I was having. You must set the
sample rate of the OutputScope of the InputBus equal to the
InputScope of the InputBus, otherwise, you'll get the CannotDo error.
How is the sample rate of the InputScope of the InputBus set? When I
do a AUSetProperty-SampleRate on the input side of the HALAU, i.e.
the side the device is hooked up to, I get a
kAudioUnitErr_PropertyNotWritable error. Going to Global scope
(still on the input element) gives a kAudioUnitErr_InvalidElement
error.
I'd assumed that setting the device's format via the HALAU would set
both the device's sample rate &, necessarily, that of the HALAU's
input side (of element == 1).
This is interesting because, theoretically, the HALAU and the
device's nominal sample rates are the same: 16k. And, the device's
stream says it's doing 16k. However, when I getProperty on the
device's actual sample rate, it returns 0.0k. What does that
indicate? Why would that be happening? The mic says it can do 16k
(and many other rates both higher & lower).
Okay, now I am confused. After the AUStart call (with a
usleep(100000) call to let things happen), I did this:
status = AudioDeviceSetProperty(mInputDesc.mDeviceID, nil, 0, true,
kAudioDevicePropertyActualSampleRate,
sizeof(Float64), &mInputDesc.description.mSampleRate);
and got a kAudioHardwareUnknownPropertyError error. The device ID is
good, confirmed by HALLab.
Ahhh, the device is not running. So there is no time stamp stream to
extract this from. So the question that I come down to: What causes
the call, AudioOutputUnitStart, to _not_ start up the device? I am
running through all of the code without errors & then hanging out
with a usleep to let things settle down before querying the state of
the device & AU. Should I be sprinkling more usleep's around the
code? Waiting for notifications at each step of the initialization?
At certain crucial steps?
Peace,
Bob
--
As a rule, one should avoid generalizations.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.