ScheduleAudioSamples problem on Windows

Hi,
I'm using Decklink Studio 4K for continuous playback (24/7) of clips in my MCR play-out application using a fork of CasparCG. From some time the CasparCG started to intermittently stop audio samples scheduling resulting of sound absence.
After some investigation I realized that:

• ScheduleAudioSamples returns OK, but *sampleFramesWritten is zero. I've made another try:
• provided NULL as *sampleFramesWritten that results with blocking kind of ScheduleAudioSamples call. In that case the function never returned.

All this seems to never happen with DesktopVideo drivers version 10.3.7 or earlier.
Moreover, frequency of the issue seems to be hardware-related - did not occur in some installations as often as in others.

The 10.4 version introduced also one more bug/feature : HDMI PAL SD output don't use one of RGB (green, AFIR) colors, and displays the other (blue) values on booth (blue and green) channels. This doesn't happen with HD formats, and earlier driver versions too. Other outputs (SDI, component) are unaffected.

Any ideas?

[Cameron Nichols]

Hi Jerzy,

Have you checked with a more recent Desktop Video driver? The most recent release is 10.9.7.

Can you try and monitor the audio frame count using the IDeckLinkOutput::GetBufferedAudioSampleFrameCount method[1]. Can you check that the audio frame count is remaining at a reasonable level and that it does not grow over time (ie new samples are written faster than they are output). As a rule of thumb, you should keep the buffered audio sample frame count to less than 1 second.

For the HDMI issue - which pixel format are you targeting for output?

Kind Regards
Cameron

Refs
[1] DeckLink SDK Manual - 2.5.3.20 IDeckLinkOutput::GetBufferedAudioSampleFrameCount method
[2] DeckLink SDK Manual - 2.5.3.1 IDeckLinkOutput::DoesSupportVideoMode method

Hi Cameron,
Yes, I checked this against 10.9.7 driver too.
Pixel format used in PAL HDMI output is bmdFormat8BitBGRA.
Regarding the audio buffer overflow, the same behavior was observed with two approaches:
- with RenderAudioSamples callback (previous method),
- with audio scheduling in ScheduledFrameCompleted callback (current method).
Initially, card buffer is filled with 3-5 frames preroll, and subsequent frames are scheduled as ScheduledFrameCompeted callback arrives, so there is no chance to overflow card buffer (if we are sure that every incoming frame has correct samples count, of course). However, I'll add warnings to log to ensure that it's not the cause. But it's IMHO unlikely.
The current code is here: https://github.com/jaskie/Server/blob/master/modules/decklink/consumer/decklink_consumer.cpp
Thanks for your help,
Jurek