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: Tue, 13 May 2008 11:39:32 -0700
Have you looked at what the IO cycle telemetry looks like for this
situation. One thing to note is that there are telemetry events that
mark when the HAL tells the driver to start/stop IO and when the
driver tells the HAL that it has finished starting/stopping IO. It
would probably be interesting to look for these events to get some
kind of sense about how they relate to each other when things work
correctly versus when they work badly.
That said, my gut reaction is that this is an application issue
though. This sounds to me like somebody is failing to account for a
clocking problem somewhere along the way. You say you are using a QT
vOut component to push video to the card and Core Audio to push the
audio to the card. Can you be more specific about what exact APIs are
involved and how you are reconciling the clock for the vOut with the
clock for the audio hardware?
On May 12, 2008, at 8:28 PM, Marc Van Olmen wrote:
I need some help trying to identify what is causing this issue.
We are using Decklink video card and we use the QuickTime vOut(video
frames) and uses coreAudio to play out the audio to the device.
Our application has been running fine for a couple of years on
several clients configurations running 24/7. But we have problem
that is coming up for different users:
The audio seems to be later then the video after a long time
(sometimes 24 hours sometimes even quicker).
I recorded a video that records both the the audio video that comes
out the decklink card:
http://www.sky4studios.com/desync/desync.mov
In this sample the delay is 12 frames (25 fps) so about 1/2 second.
But we think that there is something wrong with coreAudio or with
the audio driver of the Decklink drive. Why?
When we pause our application, the audio doesn't stop for 12 frames
(exactly the duration of the desync).
We stop the audio by the following technique: as soon the pause
action is received we start sending 0.0 samples towards the audio
output.
When there is no desync of the application this works instantly. But
when there is a desync of audio and video, the audio takes longer to
stop(duration of desync)
Also when we press the continue button, the video frames starts
right away but the audio doesn't starts playing for again exactly
the duration of the desync.
In the video above you can see the Pause/Continue button in action.
If you analyze this clip in Final Cut Pro you see what I'm talking
about.
I would love some feedback to figure out if I can proof if this is
the Decklink Driver or is it a coreAudio problem. Is there something
I can turn on in coreAudio when I hear a desync that helps me to
proof my case?
--
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