Re: handing audio dropouts with synchronized input and output
Re: handing audio dropouts with synchronized input and output
- Subject: Re: handing audio dropouts with synchronized input and output
- From: Brian Willoughby <email@hidden>
- Date: Tue, 07 Aug 2012 17:34:11 -0700
On Aug 7, 2012, at 16:05, Brian Willoughby wrote:
On Aug 7, 2012, at 12:51, Paul Davis wrote:
On Tue, Aug 7, 2012 at 3:44 PM, Jeff Smith <email@hidden> wrote:
>Why are you using 2 different callbacks for input and output?
>What exact part of the CoreAudio API are you using?
>
>(duplex applications can perfectly be managed with a single
>callback that receive input buffers and have to produce output
>buffers... this is usually simpler to develop)
In order to that, doesn't it have to be a single device (PPC) or
an aggregate device (Intel)?
there are plenty of duplex devices on Intel OS X, just not the
builtin audio device. almost all pro- and prosumer audio
interfaces ship with a duplex driver. its still a mystery to my
why apple refused to provide this for the builtin HDA interface.
Apple have not "refused" to provide this; it's a matter of the
nature of USB Audio.
CoreAudio requires that input and output share the same clock
reference in order to be a duplex device. The USB Audio Device
specification does not seem to allow for this, and thus all USB
Audio devices are seen as pairs of input-only and output-only
devices. Shipping a driver requires the user to install something
first, whereas class-compliant devices need no driver.
Basically, Apple's entire audio design presents the hardware to the
rest of the system as it actually operates, without the overhead of
any translation to some ideal or convenient standard. If you want
to treat a USB audio device as a duplex device, then your software
needs to arrange for the CoreAudio (or other) sample rate
conversion (AudioConverter) to be inserted at the appropriate point
(input or output) so that both can be treated as if they had the
same clock source even though they do not. The advantage of Apple's
approach is that you do not get the distortion of SRC unless you
ask for it, and you can control whether it happens on output or
input. An installed driver would not have this flexibility.
I just realized that I may have overstated the situation. I'm not
absolutely certain that USB Audio never allows for a shared clock
between input and output, I just recall reading that it is either
incredibly uncommon, or perhaps impossible due to the nature of the
Descriptors. But I must admit that I have not specifically researched
the limits.
Another thing is that I should have mentioned that it is still
possible to handle input and output from the same callback, provided
that the AUGraph includes an AudioConverter AudioUnit to match the
sample rates. When recording, I either shut down the output or place
the AudioConverter on the output, so that the recorded input is not
distorted by SRC. For playback, though, it might be better to favor
bit-transparent output.
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