Re: Does anyone get an AudioDevice that has both input and output channels? (question is related to software play through)
Re: Does anyone get an AudioDevice that has both input and output channels? (question is related to software play through)
- Subject: Re: Does anyone get an AudioDevice that has both input and output channels? (question is related to software play through)
- From: "Iain Sandoe" <email@hidden>
- Date: Thu, 19 Jul 2001 00:43:42 +0100
----------
>
From: "Iain Sandoe" <email@hidden>
>
To: Jeff Moore <email@hidden>
>
Subject: Re: Does anyone get an AudioDevice that has both input and output
channels? (question is related to software play through)
>
Date: Wed, Jul 18, 2001, 23:50
>
>
>
on Wed, Jul 18, 2001, Jeff Moore wrote:
>
> on 7/18/01 2:54 PM, Karl MacMillan <email@hidden> wrote:
>
>
>
>> Playing from one device to another seems likely to fail to me if those two
>
>> devices do not have a common clock source (which would be the case for
>
>> most consumer cards). This is not an issue that can be solved by
>
>> buffering because it is likely that this cards will run at different clock
>
>> rates entirely (although they will be close) rather than just clock
>
>> jitter. Do you guys have a solution to this?
>
>
>
> Yeah, it's called Sample Rate Conversion based on incoming timing
>
> information which is supplied in abundance by the Core Audio APIs. Audio
>
> apps have been doing it for years. You can too. It's not that hard. I
>
> suggest reading up on synchronization techniques in multi-rate systems in a
>
> good DSP book.
>
>
Possible of course, but this is a mega-waste of DSP power for devices that
>
*are* already synchronised - like AWACS/Screamer/Burgundy + any pro-audio
>
cards that have WORD_CLOCK (or even just I/O together).
>
>
IMHO this is a compromise to deal with
>
low-cost-don't-expect-too-much-quality devices - to do it well
>
- both latency & DSP performance will suffer greatly - shame.
>
>
>> Also, I hate to see the introduction of this extra buffering - this api
>
>> looks very promising in terms of latency (and the output only tests I have
>
>> done seem to work well) but unless 1 IOProc can deliver both input and
>
>> output I think this will always fall behind something like ASIO.
>
>
>
> ASIO can't magically unify two physically separate devices either.
>
>
no, but it can deliver defined (and potentially low) latency for devices
>
that *are* locked...
>
>
>> So again, will the built-in audio device driver be fixed?
>
>
>
> I say to you again, that if you really are going to do this, then it doesn't
>
> matter since most devices don't support it anyway. You need the general
>
> technique or you will not have this feature in your app for most audio
>
> devices because you are not willing to do the extra work or buffer up a bit.
>
>
yes, true - but don't cripple a possible real selling point - like using the
>
older generation PowerBooks as live sound processors ... it's a real shame
>
that the new machines have no inputs ...
>
>
ciao,
>
iain.