Re: HALOutputUnit (Pt 1)
Re: HALOutputUnit (Pt 1)
- Subject: Re: HALOutputUnit (Pt 1)
- From: William Stewart <email@hidden>
- Date: Wed, 4 Feb 2004 17:06:25 -0800
On 04/02/2004, at 9:23 AM, Bob Stuller wrote:
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?
The scope is global (though actually the scope arg is ignored) - what
has to be set is the element == 1 (which actually is ignored as well :)
- but the correct setting (and make sure you do this, so when we
tighten this up you don't get errors) would be: Global Scope, ElID==1
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?
The callback is there just to tell you that there is input to get. You
then call AudioUnitRender as described in the documents - That's the
*only* path you use to get input.
You don't have to provide buffer space actually (but you can) - it is
perfectly legal to call AudioUnitRender with the mData pointers in the
buffer list set to NULL. Oh, and this is *not* the thread (the thread
you get the callback notification on) to allocate memory - its the I/O
thread of the device you're getting input from.
Now that I am providing a filled-out buffer list, AudioUnitRender is
returning kAudioUnitErr_CannotDoInCurrentContext.
From what I can see this is returned when:
don't have any input data to give you
you're asking for too much data (ie. you are asking for a different
number of frames than it has kept from the I/O proc)... Thus, I
wouldn't do sample rate conversion (as this will trip this), and I'd
ask for the exact same number of frames as the device is doing I/O in.
We may remove this restriction (and thus do some buffering of the
input)...
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...
No, its generated in the call to get the input
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?
I think you're just asking for the wrong number of frames?
Bill
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.