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: Tue, 13 May 2008 19:47:01 -0400
Thanks Jeff! Love your input on this!!
On May 13, 2008, at 2:39 PM, Jeff Moore wrote:
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.
I haven't used this yet, but I will look at it and see if it can help
me.
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):
desc.componentType = kAudioUnitType_Output;
desc.componentSubType = kAudioUnitSubType_HALOutput;//
kAudioUnitSubType_DefaultOutput; kAudioUnitSubType_HALOutput
desc.componentManufacturer = kAudioUnitManufacturer_Apple;
desc.componentFlags = 0;
desc.componentFlagsMask = 0;
comp = FindNextComponent(NULL, &desc);
BAIL_NULL(comp);
BAIL_OSERROR(OpenAComponent(comp, &fOutputAudioUnit));
if (aDeviceID != kAudioDeviceUnknown) {
BAIL_OSERROR(AudioUnitSetProperty(fOutputAudioUnit,
kAudioOutputUnitProperty_CurrentDevice,
kAudioUnitScope_Global,
0,
&aDeviceID,
sizeof(aDeviceID)));
}
fAudioClockDeviceID = aDeviceID;
BAIL_OSERROR(AudioUnitInitialize(fOutputAudioUnit));
// Get the format that the AudioUnit expects us to give it
input.inputProc = cNode_AudioOutput::DoAudioOutputCallback;
input.inputProcRefCon = this;
BAIL_OSERROR(AudioUnitSetProperty( fOutputAudioUnit,
kAudioUnitProperty_SetRenderCallback,
kAudioUnitScope_Global,
0,
&input,
sizeof(input)));
in the call back I pass in the Audio samples
OSStatus DoAudioOutputCallback ( void * inRefCon,
AudioUnitRenderActionFlags *ioActionFlags,
const AudioTimeStamp * inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList * ioData)
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)?.
marc
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