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: Bill Stewart <email@hidden>
- Date: Thu, 19 Jul 2001 11:00:29 -0700
on 19/7/01 8:02 AM, B.J. Buchalter wrote:
>
Hi Jeff,
>
on 7/18/01 9:06 PM, Jeff Moore at email@hidden wrote:
>
> on 7/18/01 3:29 PM, B.J. Buchalter <email@hidden> wrote:
>
>
>
>> If individual devices don't support this, so be it -- they
>
>> are not suitable for professional audio work.
>
>
>
> Tell that to the folks working with USB devices. They might take exception
>
> to this. As Bill said, the way the USB audio spec works makes this situation
>
> come up immediately. I daresay that there will be lots of folks doing pro
>
> audio type things using USB devices.
>
The point is that people are asking these questions because they have real
>
and genuine concerns and have a desire to be able to use CoreAudio for their
>
applications, instead of having to decend back into the morass that we have
>
under OS 9.
Point taken - I think that is why we (ie. the Apple folk who are working on
this) are so actively interested in understanding these issues as you see
them.
I think so far it has been more of a clarification of the HAL design goals
and API usage than any serious flaw in the API itself. And yes we could
certainly do with better documentation :)
>
Hi Laurent,
>
>
on 7/19/01 2:01 AM, Laurent Cerveau at email@hidden wrote:
>
>
> As for the built-in hardware : having it presented as two devices or one
>
> change nothing.
>
> It is just a convenience in term of application developer, and it makes
>
> more sense as the
>
> 2 hardware DMA engines on the mac IO controller are driven by the same
>
> clock, and
>
> won't drift (so this is a good candidate for presenting synchronized
>
> IO). We are plenty
>
> aware of that. But that won't make the samples come and go faster (or
>
> slower) into
>
> the machine, or to/from the HAL :-).
>
>
Yes, but.... having a unified IOProc allows you to *know* that the inputs
>
and outputs are synchronized -- so you do not have to worry about SRC. It
>
also allows you do minimum latency software foldback/loopback in the IOProc,
>
without having to build a secondary transfer buffer. If the IOProcs are
>
split, you have to (1) divine that they are syncronized, or (2) SRC them
>
just in case. Either way, you need to add an additional buffer between the
>
two procs, which even at 64 samples, coupled with the (audio) hardware
>
latencies is starting to cross the edge of perceivability. So, as I said
>
before -- it is good that the architecture supports the unified model. It
>
will be good when the built-in audio driver supports the unified model.
>
Professional products will support the unified model. Having two syncronized
>
devices are not the same as one unified device. That is not to say that
>
application can't get around it, but is more than a matter of convienence.
Agreed - but I think Laurent was making his point to clarify that whether
the device presents two or one stream it *doesn't* effect the latency of
what the app sees from the device. But yes, it *does* effect the latency of
play-through type processing and we certainly wanted to fix that - which we
have...
Another interesting point to note is that this conversation is around the
software processing of audio data. This implies however, no limitation on
the driver as well - so functionality that should be in the driver for pro
type users can still be there, but then its an issue for a particular
driver/hardware provider to deal with. I personally think its interesting
that with this system you can provide a measurable and predictable latency
characteristic with *ANY* driver - it makes a very strong attempt to deliver
guarantees for the audio system independent of the actual driver. This is a
very different modus operandi than hardware driven systems that will
hopefully allow better, more reliable software solutions.
Bill
>
Best regards,
>
>
>
B.J. Buchalter
>
>
Metric Halo
>
M/S 601 - Building 8
>
Castle Point Campus
>
Castle Point, NY 12511-0601 USA
>
tel +1 845 831-8600
>
fax +1 603 250-2451
>
>
If you haven't heard ChannelStrip yet, you don't know what you're missing!
>
>
Check out SpectraFoo, ChannelStrip and Mobile I/O at http://www.mhlabs.com/
>
>
Download a 12 day demo from <http://www.mhlabs.com/demo/>
>
_______________________________________________
>
coreaudio-api mailing list
>
email@hidden
>
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
mailto:email@hidden
tel: +1 408 974 4056
__________________________________________________________________________
Cat: "Leave me alone, I'm trying to nap... Ah, What's that clicking noise?"
__________________________________________________________________________