Re: Lowest latency I/O
Re: Lowest latency I/O
- Subject: Re: Lowest latency I/O
- From: "B.J. Buchalter" <email@hidden>
- Date: Mon, 18 Jul 2005 11:30:47 -0400
on 7/18/05 11:17 AM, Christof Faller at email@hidden wrote:
> Dear list,
>
> My questions seem to be not concise enough: :-)
>
> I need lowest possible latency and plan to directly pass the (processed)
> sampled getting from the input callback to the output callback.
>
> In order to do this properly I have a question: Is it guaranteed that
> while I am in one callback (e.g. input) the other callback (e.g. output)
> is not called? Or do I have to be afraid that while I do input callback
> processing, the output callback may be called?
If you are running with two different audio engines (more or less two
physical devices, although USB, for example, can have more than one audio
engine for one physical device), there is no guarantee about the relative
scheduling of the IO cycle for the two engines. In particular, both IOProcs
could be running at the same time if your are on a dual processor system,
and one could interrupt the other if the amount of time spent in your IOProc
is long enough.
OTOH, if you are doing I/O with 1 IOProc on one consolidated engine (either
because the device is a Full-duplex device with one Audio Engine, or because
you have created an aggregate device from multiple Audio Engines under
10.4), then you are guaranteed that you IOProc runs as In -> IOProc -> Out
for the overall audio engine. As far as I have seen, in the aggregate case,
if the underlying IO Engines are not physically synchronized, resampling is
required for reliable operation (but I could be wrong about this; this was
the result of a quick test in aggregating the two sides of a USB audio
device -- running without resync caused clicks in the output side).
OTOH, there was a sample and some comments on this list in the past (check
the archive) about using AudioDeviceRead to get data from the input device
from the output device's IOProc; properly constructed, this could allow you
consolidate the IO cycle across multiple devices without a bunch of
additional buffering, without the need to require 10.4.
Hope this helps...
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
_______________________________________________
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