Re: HALOutputUnit (Pt 1)
Re: HALOutputUnit (Pt 1)
- Subject: Re: HALOutputUnit (Pt 1)
- From: Bob Stuller <email@hidden>
- Date: Wed, 4 Feb 2004 12:23:14 -0500
Bill et al, Greetings!
I feel bad: You wrote up this great two-part item & here I am seeking
clarification... Anyway, THANKS!
At 4:05 PM -0800 1/9/04, William Stewart wrote:
Element 0: - output if there is any
Element 1: - input if there is any - input must be explicitly enabled
with the kAudioOutputUnitProperty_EnableIO property
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 bracketted, because the client never actually directly
interacts with this side of the AU.
[snip]
In the case of a device that doesn't have a in and out (for eg, USB)
the client can register a callback with the AUHAL unit
(kAudioOutputUnitProperty_SetInputCallback) - this then will call you
when the AUHAL unit has input data for you. Please note, due to some
bugs in CA-Panther this WASN'T working as shipped - however, with the
QT 6.5 update we fixed those (so this now works for Panther and Jaguar
systems)...
Setup: G4 DP450 running Panther with QT6.5.
A couple of questions. I registered an input callback with element
== 1, the input bus if I understand this right. I get the calls on
my callback routine whether I use Input scope or Output scope. What
is the correct scope? Since I have attached a USB input device to
the HALOutputUnit, I would think that using the wrong scope would
result in an error. Looking at your diagram above & knowing that I
am dealing with an input-only device, I would think that most
anything (except disabling i/o) that I did with bus zero or the AU's
input scope would result in an error, no?
Secondly, I was surprised that the HALOutputUnit didn't provide a
AudioBufferList in the callback. The HALOutputUnit surely has (in my
situation) the converted samples in its own buffer on this side of
the kernel/user-space divide: It seemed like it would provide that
buffer list to cut down on copying. Given that it doesn't and given
that the callback fires in a thread other than my program's main
thread, am I okay calling malloc to allocate buffer space? This has
worked so far but... is it safe? If not, is there a way to know up
front how many frames the callback will be offered?
Now that I am providing a filled-out buffer list, AudioUnitRender is
returning kAudioUnitErr_CannotDoInCurrentContext. I tried to get a
hint as to the meaning of this error looking through AUBase but...
nothing; AUBase does not generate this error at all. The html
documentation only talks about it in tersm of beat & tempo...
Is there an issue with me passing most of the callback's arguments as
parameters to AudioUnitRender? The bus number looks okay, the flags
are a zero & no other value seems an improvement, the timestamp would
appear to be valid. What am I doing wrong?
Thanks in advance for any guidance you can afford me.
Peace,
Bob
--
In the depth of winter I finally learned that there was in me an
invincible summer.
- Albert Camus
_______________________________________________
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.