Possible Deadlock when calling ScheduleAudioSamples

Hi,

I'm trying to playback an NTSC video using the Decklink Duo 2. I based my code on the SignalGenerator sample for Linux.

- I prerolled 1s worth of video (30 frames).
- I then call BeginAudioPreroll()
- This triggers the RenderAudioSamples() callback
- Within the callback I call the ScheduleAudioSamples()

At this point the software hangs. I can see 2 threads waiting for some condition:

1. CDeckLinkOutput::AudioProducerThread() which triggered the callback and from which I called CDeckLinkOutput::ScheduleAudioSamples()
2. CDeckLinkOutput::AudioConsumerThread()

I was wondering what were the conditions that both the AudioProducerThread and AudioConsumerThread could be waiting on?


DesktopVideo Version: 10.6.8
SDK: 10.6.6
OS: Linux - CentOS

I managed to unlock the process; it turns out that I needed to include a pointer to sampleFramesWritten as opposed to the SignalGenerator sample which is passing NULL. I believe you should update your sample code as this is misleading, or at least return an error code and not hang my process.

I have a follow up question. What are the limitations to the number of samples I can schedule with ScheduleAudioSamples() ? I am trying to schedule 48048 samples, and only 48000 get written. Should I loop on this call until all my samples have been written?

[Nicholas Gill]

Hi Eric,

Glad to hear that you were able to resolve the issue.

I can confirm that calling IDeckLinkOutput::ScheduleAudioSamples [1] and passing NULL for the sampleFramesWritten parameter will result in a blocking write, i.e. the call will wait until all of the provided audio samples have been scheduled.

Providing a valid pointer to sampleFramesWritten will result in a non-blocking write, and the actual number of audio samples written will be returned in this out parameter. A note has been made to ensure that this point is more clearly described in the SDK manual.

The blocking that your application experienced occured because:

1. The DeckLink API allows a maximum of one second of audio to be prerolled (i.e. 48000 samples)
2. During preroll the audio streams are not running, so the audio buffer is not being drained
3. When sampleFramesWritten is NULL, the API blocks waiting to schedule all of the provided audio samples.

Please note that the SignalGenerator sample relies on this blocking audio scheduling behaviour in combination with timestamped audio (bmdAudioOutputStreamTimestamped passed to EnableAudioOutput [2]) in order to schedule audio for the 'pip' and 'dropout' signals.

In your application it may be appropriate to either use IDeckLinkOutput::GetBufferedAudioSampleFrameCount [3] in order to determine the number of buffered audio samples and then schedule enough to maintain the audio waterlevel at an application defined level, or to schedule enough audio for the prerolled video frames, e.g. using IDeckLinkOutput::GetBufferedVideoFrameCount [4].

Regarding the number of frames prerolled, please note that the minumum number of frames provided for preroll depends on the device architecture; pre-4k devices require a minimum of three frames provided for preroll, while 4k architecture devices (incl. the DeckLink Duo 2) require a minimum of two frames.

Hope that helps,

-nick

[1] 2.5.3.19 IDeckLinkOutput::ScheduleAudioSamples method
[2] 2.5.3.14 IDeckLinkOutput::EnableAudioOutput method
[3] 2.5.3.20 IDeckLinkOutput::GetBufferedAudioSampleFrameCount method
[4] 2.5.3.13 IDeckLinkOutput::GetBufferedVideoFrameCount method