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: Andy Peters <email@hidden>
- Date: Sat, 28 Jun 2008 10:29:08 -0700
On Jun 27, 2008, at 12:39 AM, Brian Willoughby wrote:
Hi Glenn,
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.
Now, to argue against my agreement: The USB spec does make things very
difficult if your device uses either a CODEC (a chip with both ADC and
DAC inside) or separate DAC and ADC chips which run off of the same
clocks. The standard Audio Class lets you define both as complete
independent. Now what happens if you change the ADC sample rate? Since
the clocking is common to both changing one necessarily changes the
other. But from the host point-of-view, you've changed only one;
there's no way for a device to inform the host that it has changed in
this manner.
So the solutions to this problem include:
a) write your own custom driver that doesn't use Audio Class at all;
b) design the hardware so that the ADC and DAC section clocking is
completely separate (no TUSB3200, no CODEC chips);
c) resign yourself to supporting just one sample frequency;
d) invent some "trick" that lets the user set the sample rate then
force the device to re-enumerate with updated descriptors reflecting
the new sample rate for both directions (Roland did this with the
UA-5(?); it has a front-panel sample-rate select switch which is read
at enumeration).
Anyways, you get the most flexibility when the OS considers the record
and playback sections to be completely separate but at a hardware-
complexity cost.
Good luck,
-a
_______________________________________________
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