Re: HALOutputUnit (Pt 1)
Re: HALOutputUnit (Pt 1)
- Subject: Re: HALOutputUnit (Pt 1)
- From: Brad Ford <email@hidden>
- Date: Wed, 14 Jan 2004 17:18:15 -0800
You must have QT 6.5 in order for this to work. There were some bugs
before this update. The order is also important. Don't try to set
the CurrentDevice property before you've set up the unit for input.
So:
1. EnableIO - enable input with SetProperty
2. EnableIO - disable output with SetProperty
3. CurrentDevice - set the device to the appropriate input device.
-Brad
On Jan 14, 2004, at 4:41 PM, Robert Grant wrote:
Hi Doug,
Well that explains why EnableIO seemed to be happy but HasIO was not.
And I was trying to do this on the OutputUnit - somewhere along the
line I didn't register the fact that even though USB devices are two
separate beasts I still need two separate HALOutputUnits (i have a
meme in my head that says "only one output unit per graph!"). I
thought you guys were doing some magic to bring them back together
behind the scenes...
So I'm now loading the Input device into a second HALOutputUnit, but
I'm still unable to get it to think it can do input... It's doing
exactly the same as before. EnableIO works and HasIO returns NO.
Does the HALOutputUnit need to be initialized before configuring the
inputs?
Thanks,
Robert.
On Jan 14, 2004, at 5:55 PM, Doug Wyatt wrote:
N.B., I am looking at the source that shipped with QT 6.5, which is
newer than what shipped with Panther. A couple things related to
input changed in the interim...
HasIO and EnableIO are different properties.
HasIO will return 1 or 0 to indicate whether the currently selected
device has any input streams (when you are interrogating the input
scope's element 1) or any output streams (when you are interrogating
the output scope's element 0). (These scope/element pairs are the
ones that are associated with the hardware, their opposites reflect
the format being communicated to the outside world.)
So if HasIO is returning 0, you may be looking at a USB output device
and not a USB input device. Or you may be encountering something that
was fixed in QT 6.5.
It looks like enabling input fails to fail if the device doesn't have
any input streams (and the same applies to output). It could be
considered a bug.
Doug
On Jan 13, 2004, at 15:58, Robert Grant wrote:
Here's my code to try and enable input on a HALOutputUnit that's
pointing at a USB audio device:
UInt32 enableIO = 1;
OSStatus status = AudioUnitSetProperty(m_outputUnit,
kAudioOutputUnitProperty_EnableIO,
kAudioUnitScope_Input,
1,
&enableIO,
sizeof(enableIO) );
if (status) NSLog(@"AudioUnitSetProperty
kAudioOutputUnitProperty_EnableIO status: %ld", status);
UInt32 hasIO = 0;
UInt32 dataSize = sizeof(hasIO);
status = AudioUnitGetProperty(m_outputUnit,
kAudioOutputUnitProperty_HasIO,
kAudioUnitScope_Input,
1,
&hasIO,
&dataSize);
if (status) NSLog(@"AudioUnitGetProperty
kAudioOutputUnitProperty_HasIO status: %ld", status);
if (hasIO) {
// Set up the callbacks etc.
}
status is coming back noErr for these but hasIO is coming back 0
indicating that input is not enabled - despite the fact that I
enabled it in the previous call.
Thanks,
Robert.
On Jan 13, 2004, at 3:43 PM, James Coker wrote:
I haven't looked at the input callbacks yet, but have to agree that
having a standard solution that will cover most cases for an AUGraph
w/ both input and output would be nice. I'm guessing that the
current
best approach would be to use two HALOutputUnits -- one (in it's own
AUGraph) for input and one (in a second AUGraph) for output, with
an appropriate buffer in between to feed data from one to the other.
Jim
On Jan 13, 2004, at 7:03 AM, Robert Grant wrote:
Just a final clarification - would it be OK to use the
SetInputCallback approach for reading audio from all HAL devices
(both uni and bi-directional)? I don't think it would but I'm just
trying to see if there's a "once size fits all" approach?
Thanks,
Robert.
On Jan 12, 2004, at 11:04 PM, James Coker wrote:
Does this imply that all, or almost all USB audio devices will
have
this setup?
Jim
On Jan 12, 2004, at 7:33 PM, Jeff Moore wrote:
Yes this is true. The USB spec doesn't require that the input
side of a device be clocked the same as the output side. They
can even be running at different sample rates and still be
adhering to the spec. From the HAL's point of view, the two
sides of the device represent two separate clock sources.
Therefore the HAL publishes them as separate devices through the
API.
On Jan 12, 2004, at 5:54 PM, Robert Grant wrote:
Thanks a lot Bill - that clarifies things tremendously. And I
think I now know why Audio In from the HALOutputUnit was not
working for me a while back - I'm using a USB Audio I/O device
and I guess that shows up as two separate Audio Devices?
Robert.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.