Re: A simple 'Device Through' app (need some help).
Re: A simple 'Device Through' app (need some help).
- Subject: Re: A simple 'Device Through' app (need some help).
- From: Brian Willoughby <email@hidden>
- Date: Sat, 28 Jun 2008 15:46:17 -0700
On Jun 28, 2008, at 10:29, Andy Peters wrote:
On Jun 27, 2008, at 12:39 AM, Brian Willoughby wrote:
I recently simplified CAPlayThrough to deal with an 20-in, 22-out
device (of which I only needed 7 in and 2 out). However, I've got
some bad news for you: The only way to simplify things is when you
have a device where input and output are not separate. Since
you've already told us that input and output are separate devices
(this is a USB-Audio device, right? - well, you can thank the
designers of the USB specification for that harsh reality),
I have to agree with Mikael here ... there is no good reason why
the ins and outs need to be part of the same "device." And in fact,
you can imagine a case where the inputs run at one sample frequency
and the outputs run at another.
There's a lot less disagreement here than you might think. CoreAudio
handles both the case where the in and out are the same device, and
when they are not. CoreAudio even supports multiple levels - direct
access versus abstraction. The only thing that CoreAudio lacks is an
even higher level abstraction which handles everything
automatically. The complaint is that this lacking requires
programmers to come up with the code themselves.
The oldest part of CoreAudio is the HAL. When programming at that
direct level, you always connect separately to input and output, and
thus you're always prepared to deal with the variety of hardware
configurations (so long as you can detect when SRC is needed). But
this requires a lot of programming which goes beyond the beginner level.
The 'newer' part of CoreAudio is the output audio units, which handle
many things automatically, and also happen to present input together
with output - but only when they come from the same device. This
part of the API is much easier than the HAL, but it still stops short
of handling absolutely everything automatically. This is also the
recommended API for most audio programmers, especially beginners.
CAPlayThrough provides sample code that will combine input and
output, even if they are not the same device. One could argue that
this should be part of the API, somehow, since this is a useful
feature that is provided by other audio API. Maybe some day it
will. For now, just be thankful that we're no longer forced to work
exclusively in the HAL.
This could be another example of "Be careful what you ask for."
There are already situations where iTunes distorts the audio because
of all the automatic conversion happening in the output audio units.
Not the kind of distortion that would bother the average user
listening on their build-in speakers, but certainly a problem for
audiophiles who are paying top dollar to listen to 24-bit 96 kHz
recordings on appropriate audio systems. If and when CoreAudio
offers automatic play-through coalescing of USB devices that have
divided input and output, this will be yet another area where lack of
direct control will allow unplanned distortions. The philosophy of
CoreAudio is to start with precise direct control of the hardware,
and build from there. We should understand that simplicity does not
come without a price. Admittedly, CoreAudio could make things a lot
simpler for newbie programmers that have never written an audio
program before. But there is also an advantage in having access to
the precision of direct control. Competing API do not offer the same
undistorted control of such a wide variety of audio hardware.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden