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: Marc Van Olmen <email@hidden>
- Date: Thu, 15 May 2008 23:31:03 -0400
On May 15, 2008, at 2:28 PM, Jeff Moore wrote:
On May 13, 2008, at 4:47 PM, Marc Van Olmen wrote:
Thanks Jeff! Love your input on this!!
Sorry this reply took so long.
On May 13, 2008, at 2:39 PM, Jeff Moore wrote:
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?
Of course this was our first reaction, that it would be in our
application, but our application telemetry data indicates that the
Last Audio frame and Last video are being send to the different
API's (vout and coreAudio) in 1 Frame duration 1/25 accuracy. For
my telemetry I use the CPU clock , for the playback I use the video
clock of course...
Here is another reason why I think it is something to do with
coreAudio API or Decklink driver:
For coreAudio I use the following API (I can give more details if
needed):
<Output Unit code>
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?
- 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.
Now as soon somebody press the Pause button I start outputting 0
samples in this call back DoAudioOutputCallback. So I'm currently
assuming that this will be right away done. But what I notice that
there is a 1/2 second delay before the samples becoming zero. (This
is only in the case there is noticeable desync, otherwise the audio
indeed it is right away.
Is it possible that the call back is calling me like 1/2 second
ahead? My experience is that the DoAudioOutputCallback is always
output (almost immediately)?.
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?
thanks
marc
_______________________________________________
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