Potential Floating Point Error with null audio?

[Bruce Richardson]

Hi Mike,

Hope you've been well. I have encountered a "crackle/pop" bug at the top of cues which I am fairly sure is caused by a CPU spike. The bug manifests when creating an audio cue made up of several audio subcues, some of which are streaming silence at the top. In my case, I use this technique when creating an effect or music mix which is assigned to various speaker groups in house, creating a discrete "surround" type mix. To keep things in sync (a dry signal in one place, for instance, with its reverb tail in a separate file playing in another), it doesn't work as dependably to delay the subcue files...they don't seem to start sample accurate unless they start at zero.

I am not sure if it was introduced in 10.6.1. I upgraded from 10.5.x before this show (skipped 10.6.0) and didn't ever experience this problem before...and I have created many designs in the past using this technique, so I don't think it has always been there.

The issue doesn't seem to be related to any other issues--I switched out hardware, etc., in the diagnosis process. I've been a part of several test groups with DAW software and plugins, and this kind of runaway CPU error is encountered by almost every developer at one time or another (streaming "absolute zero" audio causing some sort of runaway loop in the floating point system, therefore creating a CPU spike). If I remember correctly, the "cheap" fix is to add a super-low level DC offset somewhere in the mix engine, so that there is never a "true zero" stream. I know just enough about software development to be dangerous and worthless, so hopefully my report will allow you to better evaluate what's happening.

At any rate, I'm pretty sure I've eliminated any other potential cause...working around the problem has involved going into the offending cues, and delaying the cue start/cue delay by equal amounts so that all these "zero files" don't start streaming at once. That fixes the "pop" at the top of the cue...

Best regards,
Bruce

[jkowtko]

could this be related to the "static burst" issue we've seen (very intermittently) in the past?
See post: http://www.showcuesystems.com/forum/vie ... &hilit=ac3

[Mike Daniell]

What file type are you using, Bruce? WAV, FLAC, etc? Also, are you using the SCS internal mixer? If so, are you using ASIO?

[Richard]

Hi all,
I remember reading somewhere that true digital silence, i.e. all bits set to zero, is a bad idea, it causes digital distortion. Something to do with the fact that with a 16 bit recording the maximum s/n ratio is about -96dB and truncation errors and dithering. My understanding of all this is a bit vague Anyway try using a bit of low level noise rather than digital silence, stick the noise up above 15kHz and nobody will hear it anyway.

Cheers
Richard

BTW. a DC offset is a good way to fry your speakers

[Bruce Richardson]

Mike: It's WAV, in this case 16/44.1 for the entirety of the show's cues.

[Bruce Richardson]

Internal mixer: Yes. ASIO: Yes.

[Mike Daniell]

Can you try using WDM instead of ASIO? Let me know if that fixes the problem. If it doesn't, can you try not using the internal mixer?

[Bruce Richardson]

Hi Mike,

Let me try. This has been a vexing problem to be sure. I have so many things assigned to single outputs in this show that the routing is a challenge. We switched venues and last night was a tech where I was better able to hear the problem. It is definitely a "mini-burst" type, comes off as a loud pop but seems to be a short burst of full-band noise. Definitely related to cues with multiple audio sub-files that have digital silence.

B.

[Bruce Richardson]

Mike, thanks again for the quick help.

Here's the report:

Going to WDM drivers solved the popping/bursting issue. So the bug is ASIO related as well.

New problem, though. Now that I've switched to WDM drivers, the sync between playing positions is intermittently off. There is also considerably more latency. I had the "force internal mixer" box unchecked. I've rechecked it, and am going to observe that.

Is there anything I can do (besides lock the sync on hardware devices, which I've done) to help keep everything in sync? The Layla/Delta are wordclocked together.

Using the ASIO drivers seems much more efficient and stable, locking wise. But the burst phenomenon is definitely a deal killer.

B.

[Bruce Richardson]

Here is an update on the situation:

Sync problems with WDM drivers seem related to audio cues which overlap, that are not assigned to the same output pairs. A simple example:

Cue One is assigned to Apron Fills, Towers, and Subwoofer. As it is fading Cue Two begins. It is assigned to Apron Fills, Towers, Surrounds, and Subwoofer. But Surrounds are out of sync when the playback overlaps.

The workaround is to assign Surrounds, silently, to Cue One. Because the two overlapping cues are now assigned to exactly the same send channels, there is no sync problem between output channels.

This problem did not occur with the ASIO drivers. Only after I switched to WDM drivers, to solve the initial problem of the static bursts on cues which contained digital silence.

In short, on complex multichannel shows with streamed silence, ASIO is not an option becuase it creates static bursts. But WDM is equally problematic because of the sync problem created when cues of differing output assignments are overlapped.

[Mike Daniell]

Can you email me your cue file (the .scs file) and tell me which cues are involved in this issue?

[Bruce Richardson]

Hi Mike,

I'll get it to you after this show closes this weekend.

The ASIO drivers work much better than the WDM, in terms of the quickness of response, tight timing, etc. The WDM drivers introduce that sync problem, which I have actually had on previous shows. The workaround is always to have the channels open (even if playing back at -inf) in the previous cue. This keeps all the different outputs sync'ed.

What is telling in the situation is that the outputs that don't sync are contained within the same audio interface, even though I'm using two different interfaces, wordclocked together. I would have expected the problem to exist between the two interfaces, but that was not the case.