Re: HALOutputUnit (Pt 2)
Re: HALOutputUnit (Pt 2)
- Subject: Re: HALOutputUnit (Pt 2)
- From: Bob Stuller <email@hidden>
- Date: Tue, 24 Feb 2004 22:18:07 -0500
Aaron, Greetings!
At 6:01 PM -0800 2/24/04, Aaron Eppolito wrote:
On Feb 24, 2004, at 3:16 PM, Bob Stuller wrote:
> 1) The input (device) scope is a read-only property for format in
general and sample rate in particular.
I don't know if the input scope of the input bus is read only, but the
device properties can be set with
AudioDeviceSetProperty(...kAudioDevicePropertyNominalSampleRate...)
This I do.
> 3) I'm always going to find the output end's sample rate to be 44.1kHz.
It always starts out that way; that's why you need to set its output
scope to be equal to its input scope.
Therefore, I can _only_ get 44.1kHz out of the HALAU.
No. You can only get out what it gets in. Since #1 is flawed, this
whole reasoning is flawed. Also, even if your device only did 44.1,
you could always put an AUConverter into the graph and have it convert
to whatever sample rate you want (I think; I've not tried it...)
(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.
I thought that Bill Stewart had said as much in his definitive tome,
HALOutputUnit (Pt 1 & 2):
Graphically, you can visualise the signal flow like this:
"Render Callback" side (AU's input side)
Client (Device Input)
| |
0 | 1 |
AUHAUL
Unit
"AudioUnitRender" side (AU's output side)
0 | 1 |
| |
(Device Output) Client
The (Device) is bracketed, because the client never actually directly
interacts with this side of the AU.
and:
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!
> So I simply cannot do what I feel I need to do using the HALAU.
Bummer!
Not true. This should work. Simply: ("simply" in quotes)
* Set the device sample rate with
AudioDeviceSetProperty(...kAudioDevicePropertyNominalSampleRate...)
* Get the input bus' input scope's ASBD
* Get (or create) the input bus' output scope's ASBD
* Set the sample rate to be equal to the input rate
* Set the input bus' output scope's ASBD to be the one you just
created/modified
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?
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.
Well, interestingly, it partly did work: I started get garbage data
again. That is, AudioUnitRender doesn't say 'not in this context'.
But the device, according to HALLab, didn't get set to the 44.1kHz...
That suggests that the next to do would be set the device's sample
rate manually. Hmmm... That didn't get it going ... but didn't make
it worse either.
FYI: It seems I use bus interchangeably with element. I'm not sure
which is the right term...
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.
On Feb 24, 2004, at 5:38 PM, Doug Wyatt wrote:
> Aaron -- that is true in general, but not for the output(/input) unit,
which fetches the format from the hardware. I see the line of code
that should be doing it ...
(I should also pick a nit and clarify -- all units *default* to 44.1,
but in most if not all, the stream format can be changed before
> initialization -- except on the converter and I/O units, which allow
the format to be changed after initialization)
Uh, that's what I thought too, but unless I init the output scope of
the input bus, it insists on being 44.1kHz, and Bill said that that was
to be expected. The *input* scope of the input bus gets init'ed, but
seemingly not the *output* scope of the input bus.
Oh, and by the way, I'm not a CA engineer, so take anything I say with
a grain of salt, and anything they say as gospel... =)
Doug says it can be done. Glad to hear that that is gospel!
I'm east coast so I will say good night to all... hopefully the
answer will come in a dream.
Peace,
Bob
--
It's Great to be Green!
http://www.greenpartyus.org/
_______________________________________________
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.