Re: Need help to identify Audio Output issue
Re: Need help to identify Audio Output issue
- Subject: Re: Need help to identify Audio Output issue
- From: Jeff Moore <email@hidden>
- Date: Fri, 16 May 2008 11:16:06 -0700
On May 15, 2008, at 8:31 PM, Marc Van Olmen wrote:
On May 15, 2008, at 2:28 PM, Jeff Moore wrote:
My only questions about this is:
- How are you dealing with the time stamps from the audio hardware
and correlating that to the video time stamps?
- Are you checking for overloads and/or other time stamp
irregularities? If so, how are you handling them. If not, I think
you really ought to be.
Currently I'm not checking for overloads. Any suggestion on what I
look for?
I can do some logging of the AudioUnitRenderActionFlags and see if
they send me something different sometimes? Is that a direction I
should go?
You need to be paying attention to the device's
kAudioDeviceProcessorOverload notification. Overloads are indications
of a problem somewhere along the pipeline that prevented the IO
cycle's real time deadline from getting met. When you get one of these
notifications, it's a good time to have your engine resynch itself to
the hardware because there has been a discontinuity in time.
- How are you coping with the presentation latency in the audio
hardware?
The latency is non existence at start up, but sometimes we have now
the desync issue: so suddenly after a few hours it starts to appear,
we haven't identify yet, that it appears gradually or that it
appears abruptly.
Ah. So you aren't really doing anything with the device latency it
would seem. I imagine that as long as the audio hardware's latency is
less than a video frame, you probably haven't been noticing any
problems.
Still, there are devices out there with non-trivial latencies. So to
be completely safe, your application needs to account for this latency
in it's calculations for when to start the audio and video relative to
each other for proper synch.
Yes that is possible. What is the latency and safety offset figures
for the device? They represent a reasonable estimate about the
buffering in the device and might be quite large.
Hallab.app says for the Decklink Audio: Latency:0 and Safety offset:
0 does this mean that 1/2 second delay should not be possible?
That would actually mean that the Decklink driver has a problem. By
not providing these numbers, there is basically no way for your app or
the HAL to behave properly with this device. You can't account for the
presentation latency in your synchronization calculations and the HAL
can't know how far ahead it has to be to deliver the the data in time
for it to be delivered to the hardware.
In fact, I would bet money that the problem you are seeing is directly
tied to the lack of an accurate safety offset figure from the driver.
My guess is that because the safety offset is 0, the HAL is sometimes
actually falling behind the driver. If this were happening (and I've
seen it happen before with other drivers), it would make all your data
come out with a delay equal to the size of the driver's ring buffer
which I imagine is in line with your half second observation.
My advice would be to report this problem to the developer of the
driver and to keep in mind this in mind when using this device.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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