Re: HALOutputUnit (Pt 2)
Re: HALOutputUnit (Pt 2)
- Subject: Re: HALOutputUnit (Pt 2)
- From: William Stewart <email@hidden>
- Date: Wed, 25 Feb 2004 12:14:32 -0800
A couple of comments...
Terminology - we like to call this the AUHAL unit - because that's its
name, and its been complaining to me recently that it has a bit of an
identity crisis and doesn't really know who this HALAU fellow is :)
On 25/02/2004, at 10:20 AM, Aaron Eppolito wrote:
>
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.
The rule of thumb as has been described is that you can't set the
devices format with the AUHAL unit - you have to go to the device
itself. This has *always* been true...
We are getting a technote together with a diagram that will summarise
all of these points, so this should make this easier to deal with in
the future.
>
Before the steps above. And no, the order DOES matter.
The point Doug was making is still true. (And I might add some further
comments to that).
As far as setting the format of *what you want* that can be done at any
time - and by that I mean that normally with any AU you can't set its
formats after its been initialised (for instance all of the effects
that we ship validate that their format is correct at initialisation) -
this is also true of 3rd party AU's and is a recommended practise for
these.
However, we relax that in the Converter based units (the AUConverter,
AUHAL and its children), because for the AUHAL units they have to
respond to changes in device formats anyway...
The one restriction (difference) between the input and output sides of
AUHAL is that getting input from a device must be in the same sample
rate as the device (this is *not* true for output). Why? Because
currently AUHAL doesn't do any buffering of the device input and if
there were an SRC involved there would need to be... We'll probably
lift this restriction at some point.
The other thing to note after these steps, is that if you have a
mismatch between the device's available channels (lets say it has 10)
and what you want (lets say 2) - you can use the channel map property
to describe which channels of the device you want your data to go
to/from. This is true both for the input and output cases (and was
covered in my email and will be covered in the technote)... If you
don't set a channel map, then you basically go to/from the first 2
channels of the device (in the example above)
>
13 - in your callback, call:
>
AudioUnitRender(unit, 0, timestamp, 1, frames, bufferlist);
This is not quite right!
You CANNOT pass in a NULL value for the render flags to
AudioUnitRender. This will cause either param errors or crashes. The
value of the flags should be zero thus:
AudioUnitRenderActionFlags flags = 0;
AudioUnitRender (unit, &flags, ×tamp, 1, numFrames, bufferlist);
You have been warned :)
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement
I sais, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
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.