RemoteIO - missed deadline - incorrect timestamps
RemoteIO - missed deadline - incorrect timestamps
- Subject: RemoteIO - missed deadline - incorrect timestamps
- From: Zachary Kulis <email@hidden>
- Date: Tue, 09 Nov 2010 11:30:33 -0500
Hi all,
I'm working with the RemoteIO unit and the PlayAndRecord audio session
category. In, my application, I am trying to time-synchronize output
samples with input samples. To do this, I use the value of mSampleTime
in the AudioTimeStamp that is provided to the RemoteIO output and input
callbacks. Most of the time, everything works fine and I can synchronize
the output/input samples successfully.
I've noticed, however, that is it possible for the system to drop a
RemoteIO callback, especially under heavy system load. For example,
performing file IO in a separate thread may cause the OS to miss a
deadline for invoking the RemoteIO input callback. The result is that I
may get 2 RemoteIO output callbacks in a row (the input callback is
dropped by the system).
This situation would normally be OK; I've implemented logic that detects
a missed callback and resets the synchronizer. It appears, however, that
the audio timestamps are not correct after a missed callback. For
example, I've noticed that the difference between the output and input
timestamps increases monotonically for each missed callback. When I
start the application, the difference is 1160 samples. This number
increases to 2535, then to 4000+, etc. for each missed callback.
I've verified that the timestamps are indeed inconsistent; if I delay
the input samples by the computed difference, the input samples will
actually *precede* the corresponding output samples! If, however, I
leave the sample offset at 1160 (the original difference), then the
samples appear to be synchronized.
It is easy to demonstrate the above problem by repeatedly toggling a
breakpoint while running an application that uses the RemoteIO. In this
case, however, it appears that it is possible for the samples to get out
of sync - using the original 1160 value may not always synchronize the
samples. Does toggling a breakpoint change something in the underlying
audio hardware that would cause the sample offset to change?
My questions are the following:
1) Is the delay between the output and input samples fixed by the audio
hardware? I would expect the delay to depend on the hardware IO buffer
size. I am using a buffer size of 23 ms, which is equivalent to 1024
samples (44.1 kHz). Thus, the value of 1160 seems reasonable for the
buffer size.
2) Should the timestamps be inconsistent if a RemoteIO callback is
dropped by the system?
3) Does the RemoteIO ever buffer input samples? I want to ensure that
the samples I receive in the input callback are the most recent samples
available. Does the behavior depend on whether
kAudioUnitProperty_ShouldAllocateBuffer is enabled?
If anyone could provide information regarding these issues, I would be
most grateful!
Thanks in advance,
Zach
_______________________________________________
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