Re: HALOutputUnit (Pt 2)
Re: HALOutputUnit (Pt 2)
- Subject: Re: HALOutputUnit (Pt 2)
- From: Aaron Eppolito <email@hidden>
- Date: Wed, 25 Feb 2004 10:20:30 -0800
On Feb 24, 2004, at 7:18 PM, Bob Stuller wrote:
(I went & tried this again, just to be sure.) When I try setting both
the HALAU's input scope sample rate & format, I get a
kAudioUnitErr_PropertyNotWritable error.
You are setting the wrong scope. Read what I wrote again. You need to
set the OUTPUT scope of the input bus. I think you need to wrap your
head around scopes. Let's envision one bus for a moment (just the
input side, i.e. recording samples from the device). The HALAU has two
sides of the bus, one side that talks to the device (the input scope)
and one side that talks to you (the output scope).
SoundCard --> [ input scope == HAL AU input bus == output scope ]
--> Your Code
The input scope is set by the device. Obviously the HALAU's input
scope must match exactly what the device is giving it. That's why you
can't set it. It pays attention to what the device is set to. The
OUTPUT scope on the other hand, is what you set. You can set any
format you want as long as the sample rate matches the input scope and
the number of channels is <= the input scope.
For Device Input (AUHAL's Element 1), the device format is always
expressed in the input scope and is not writable as described above.
Of course, this does leave me wondering a couple of things. We get to
set the format of the output side of the input bus & that action seems
to carry over to the device... but not to the input side (of the input
bus/element). Odd!
You set the output scope because that's the format you're requesting to
be given. I am a little surprised that the input scope isn't writable,
but since that's exactly what AudioDeviceSetPorperty() does, it's not
the end of the world. And no, setting the output stream format should
have no bearing on the device.
Question: At what point do you attach the device to the HALAU? I
gather that the HALAU is one of the entities that can have its format
changed after initialization... so the order that this is done should
not matter. Would you agree with that assessment?
Before the steps above. And no, the order DOES matter.
Okay, here's a list of ALL the steps I take.
1 - set the device sample rate:
AudioDeviceSetProperty(deviceID, 0, 0, true,
kAudioDevicePropertyNominalSampleRate, size, &rate)
2 - open either a "graph and AUHAL node" or just a "AUHAL Audio Unit"
3 - enable input:
AudioUnitSetProperty(unit, kAudioOutputUnitProperty_EnableIO,
kAudioUnitScope_Input, 1, ...)
4 - set device:
AudioUnitSetProperty(unit, kAudioOutputUnitProperty_CurrentDevice,
kAudioUnitScope_Global, 1, deviceID, size);
5 - get the inputScope inputBus ASBD:
AudioUnitGetProperty(unit, kAudioUnitProperty_StreamFormat,
kAudioUnitScope_Input, 1, &inASBD, &size);
6 - get the outputScope inputBus ASBD: (you could also just create one
to be what you want)
AudioUnitGetProperty(unit, kAudioUnitProperty_StreamFormat,
kAudioUnitScope_Output, 1, &outASBD, &size);
7 - adjust the outputScope inputBus ASBD to match the sample rate of
the input:
outASBD.mSampleRate = inASBD.mSampleRate;
8 - set the outputScope inputBus ASBD:
AudioUnitSetProperty(unit, kAudioUnitProperty_StreamFormat,
kAudioUnitScope_Output, 1, &outASBD, size);
9 - hook up the input callback:
AURenderCallbackStruct callback; callback.inputProc = foo;
callback.inputProcRefCon = this;
AudioUnitSetProperty(unit, kAudioUnitProperty_SetInputCallback,
global?, 1, callback, size);
10 - alloc buffers
11 - initialize AudioUnit or AUGraph (depending on if you used a graph
or not)
12 - start graph or unit
13 - in your callback, call:
AudioUnitRender(unit, 0, timestamp, 1, frames, bufferlist);
I will give this methodology a quick shot. It probably will work...
for an unfortunate reason: This will force the whole mechanism to go
to 44.1kHz. And that is exactly what I'd like to avoid.
No, no, no. The first step above sets it to whatever sample rate you
want. Where do you ever see 44.1 after that? If you're getting
44.1kHz at step 5, it's because your device couldn't do the sample rate
you asked.
B-) Glad to hear that I am not the only one. I spent a long period
confused about "the output end of the input bus" etc.
Well, I was confused between scope and element/bus as well, but those
terms are NOT interchangeable. See above diagram.
Doug says it can be done. Glad to hear that that is gospel!
I'll say it can most certainly be done too, because I (and probably
others) are doing it for arbitrary sample rates.
-Aaron
_______________________________________________
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.