Re: AudioDeviceRead / HALOutputUnit
Re: AudioDeviceRead / HALOutputUnit
- Subject: Re: AudioDeviceRead / HALOutputUnit
- From: Jeff Moore <email@hidden>
- Date: Thu, 5 Feb 2004 12:03:45 -0800
On Feb 5, 2004, at 10:55 AM, Tim Dorcey wrote:
My app captures audio from the default input device using
AudioDeviceAddIOProc()/AudioDeviceStart(). It uses
AudioDeviceAddPropertyListener() to listen for changes in
kAudioDevicePropertyStreamFormat and reconfigure an AudioConverter
accordingly. Captured audio is sent over network for a telephony like
application. It seems to work fine, although I am getting some
reports of
spontaneous changes in input gain, and I haven't really examined
efficiency/performance (was just happy to have it working).
That sounds like a very reasonable architecture. It will perform
reasonably well. About the only thing that you might change is when you
call the AudioConverter. You might find that you get better performance
if you take the data you get in the IOProc, put it in a queue or a ring
buffer or something like that, and then use another thread that to
process the data. This consumer thread would be the guy making the
calls to convert the data into the format you want to send across the
network.
Should I be looking at using an Output AU for this? Or, do I
misunderstand
the context of the discussion below?
The Output AU could make the amount of code you have to write smaller
since it already will do the heavy lifting of being a proper HAL
client. But since you have something that works, whether you change
depends on how much you feel like re-writing.
Has anyone else seen apparently spontaneous changes in input gain? I
guess
I could listen for changes in kAudioDevicePropertyVolumeScalar? But
not
sure how I would tell the difference between a user desired change, and
whatever else may cause it.
Some apps out there do whack the input gain of the device when they
launch. Listening would allow you to know when the change takes place
at least, although it won't help you at all with knowing the user's
intent.
I don't know if you are doing this already, but you might want to
consider using a compressor/limiter to smooth the volume spikes out
before handing things off to the converter to encode. This can result
in a clearer signal and that won't be as spiky. Just a thought.
Tim
-----Original Message-----
From: email@hidden
[mailto:email@hidden]On Behalf Of Jeff Moore
Sent: Wednesday, January 14, 2004 11:11 AM
To: CoreAudio API
Subject: Re: AudioDeviceRead / HALOutputUnit
Yes, for two primary reasons:
First, the Output AU does all the hard work of being a proper HAL
client. There are a lot of details involved with this for a general
applications, so the work saved by doing it is immense, especially if
you are already using the Output AU for other things.
Second, not every device supports AudioDeviceRead. Currently, the
popular examples of devices that don't are Digi hardware and the
iSight, and the future has more on the way.
Generally speaking, I recommend that everybody use the AUs
rather than
using the HAL directly.
On Jan 14, 2004, at 7:25 AM, Chandrasekhar Ramakrishnan wrote:
If one already has code that uses AudioDeviceRead to get audio input
that you feed into an AU graph, is there any reason to switch to the
HALOutputUnit input capabilities?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.