Re: Does anyone get an AudioDevice that has both input and output channels?
Re: Does anyone get an AudioDevice that has both input and output channels?
- Subject: Re: Does anyone get an AudioDevice that has both input and output channels?
- From: Lubor Prikryl <email@hidden>
- Date: Sun, 22 Jul 2001 23:55:39 +0200
Thanks, it was very helpful discussion. I am developing a host app for
VST plugins on X, which is to be used in real time, I will test your
3ms...
My questions:
Does Apple provide a generic audio driver for FireWire/ OS X?
Will you give us an example of some audioUnits and their connection to
the graph?
Thanks
Lubor Prikryl, DSound,
email@hidden
On Thursday, July 19, 2001, at 10:05 PM, Jeff Moore wrote:
on 7/18/01 9:06 PM, James McCartney <email@hidden> wrote:
At a cost of how much additional CPU overhead compared to 128 or 256 ?
My profiling numbers (which anyone can replicate on their own systems)
indicate that there is very little extra overhead involved with smaller
buffers beyond the obvious things like more function calls per second
and
the consequences that go with it. Here's why:
- Smaller buffers do _not_ mean more hardware interrupts per second on
this
system. The number of hardware interrupts per second is _constant_ no
matter
what the user land apps do with their buffers.
- The HAL's IO thread is woken by a timer that is otherwise always
running
on the system, so there is almost no extra overhead for waking it more
often
with smaller buffers.
- Further, the HAL's IO thread's scheduling latency is very small
because it
is among the highest priority threads in the system. The scheduling
latency
will vary with the load on the system (outside of the IO thread) and the
number of processors.
- The overhead in the HAL for running it's duty cycle and managing the
IOProcs is constant and does not vary with the buffer size. It is also
very
small.
- The CPU usage of the driver's mix and clip operations vary directly
with
the buffer size and the number of active IOProcs, but should remain
constant
in terms of relative percentage of the time used out of the duty cycle.
Plus, smaller buffers mean that more of them can fit in the level 2
cache
and improve the dsp performance modestly.
So, while you _will_ get a modest increase in CPU utilization and the
fixed
overhead _will_ eat more and more of the total duty cycle as your
buffers
get smaller, the performance envelope you will see is a lot different
than
interrupt driven, double-buffered architectures in other systems.
Hope this helps clarify things a little.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list
email@hidden
http://www.lists.apple.com/mailman/listinfo/coreaudio-api