Re: AudioDeviceRead / HALOutputUnit
Re: AudioDeviceRead / HALOutputUnit
- Subject: Re: AudioDeviceRead / HALOutputUnit
- From: Jeff Moore <email@hidden>
- Date: Thu, 5 Feb 2004 15:35:32 -0800
On Feb 5, 2004, at 3:11 PM, Tim Dorcey wrote:
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.
In this day and age I have learned that "works" is a relative term
:-). The
only identical systems are ones that haven't shipped yet, so it's hard
to
learn much just by testing (I remember the old days when "if it worked
on
one Mac it worked on every Mac" was very nearly true... and what a rude
awakening were my first forays into the Windows world where everyone
seemed
to run a slightly different version of the OS). Anyway, I guess what
gave
me pause in your post is that I didn't feel like I did a lot of heavy
lifting, so figured maybe I am not being a proper HAL client. I can
say it
"works" on 1000's of different systems, but can't say how many it
won't work
on today or in the future. Will I run into system configurations where
simply installing IOProc and listening on StreamFormat is less
dependable
than output AU?
Just listening for the stream format to change is definitely not enough
to be a good HAL client. There are a myriad of things that can happen
that affect how the data is delivered that you really ought to be
paying attention to, not to mention the fact that audio devices like to
have a variety of streams in all sorts of configurations that make a
simple set-up like this fall down. This is why I recommended the AU.
Re performance, I did think about moving the
AudioConverterConvertBuffer
call out of the ioProc, but my target format is simply 8Khz, 16-bit
integer,
mono. Guessing that many devices will be delivering 44Khz, floating
point,
stereo, I figured the immediate 22:1 reduction in the amount of data
to be
moved around would justify doing some extra arithmetic "at the wrong
time."
Truthfully, I did it that way to avoid re-writing existing code that
encodes
and writes to network from old-style "Deferred Task" installed from
ioProc
(which seems to continue "working" fine on OSX).
The reasoning behind this recommendation is to reduce the amount of
time you are spending in your IOProc, which is running on one of the
highest priority threads in the system. The less time spent in it, the
more responsive the system is (in general).
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
This seems to be unrelated to any user activity, as if there is
something
secretly running in the background that likes to occassionally double
or
halve the gain. Need to gather more info from the systems where this
is
happening.
I'd be very curious about your findings. Please file a Radar bug if you
believe that it is some kind of misbehavior on the part of the system
somewhere.
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.
Yes, I did exactly that, and it significantly improved the audio
quality,
though I had figured it was due to limitations in the particular audio
codec
I am using, rather than a "generally good idea."
Yup. A compressor can really kick up the quality of a lot of speech
codecs. You might even want to try out our multi-band compressor AU to
do this.
--
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.