Audio cue cut out

[stevenso...@gmail.com]

Hello

I have a project that has been working fine for a long time now. However on the last two shows the audio has cut out in the same cue! I have tried to re-create this at home (after it did it on the first show, then again after it did it on the second show) with everything set up the same (two iPads connected with the same access point, usbdmx dongle connected, midi controller for GO button connected) and it has worked perfectly every single time.

I am lost!

The system is a MacBook Air running 10.10.4 (the OS it shipped with, had no problems before so therefore like to stick with what works). The audio interface is a Scarlett 2i4 1st generation.

Possible solutions I have yet to try...

- Update OS to latest (would rather not, is High Sierra show stable yet?)

- Reset SMC & PRAM (do we think this might work?)

- Rollback Qlab to an earlier version. (this has happened on 4.1.4 and 4.1.5, the latest at the time of the shows)

- Update Qlab (to 4.1.6 from 4.1.5)

The reason I have yet to try any of these is because I wanted to try and re-create the problem before attempting to fix it but it doesn't seem like I am able to without actually doing the show. The only differences between running it at home and at the actual show that I can think of has been

- Nothing connected to the usbdmx output (I figured having the dongle connected would be enough to recreate the CPU load)

- Power supply (extension, not MacBook charger)

I don't have the computer with me at the moment, but I do have this from the console log I snatched...

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioDictionary at line 3092

2 Dec 2017 20:12:15 kernel: Unable to locate terminal ID=0

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioDictionary with return 0xE00002BC at line 1625

2 Dec 2017 20:12:15 kernel: USB Sound assertion in AppleUSBAudioDevice at line 1027

2 Dec 2017 20:12:15 QLab: Warning: audioDeviceDidOverload: Scarlett 2i4 USB

2 Dec 2017 20:12:15 QLab: Error: 2003332927 [?ohw] | -[F53AudioDevice _stringForProperty:] [line 579]

2 Dec 2017 20:12:15 QLab: Warning: audioDeviceDidDie: *nil description*

2 Dec 2017 20:12:15 QLab: Error: 2003332927 [?ohw] | -[F53AudioDevice _stringForProperty:] [line 579]

2 Dec 2017 20:12:15 QLab: Warning: audioDeviceDidDie: *nil description*

2 Dec 2017 20:12:19 VDCAssistant: VDCAssistant:  Found a camera (0x141000001235800a) , but was not able to start it up (0x0 -- (os/kern) successful)

2 Dec 2017 20:12:19 VDCAssistant: VDCAssistant:  Found a camera (0x141000001235800a) , but was not able to start it up (0x0 -- (os/kern) successful)

2 Dec 2017 20:12:22 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:22 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:22 kernel: USB Sound assertion in AppleUSBAudioStream at line 4804

2 Dec 2017 20:12:22 QLab: Warning: audioDeviceDidOverload: Scarlett 2i4 USB

2 Dec 2017 20:12:22 QLab: Error: 2003332927 [?ohw] | -[F53AudioDevice _stringForProperty:] [line 579]

2 Dec 2017 20:12:22 QLab: Warning: audioDeviceDidDie: *nil description*

2 Dec 2017 20:12:22 QLab: Error: 2003332927 [?ohw] | -[F53AudioDevice _stringForProperty:] [line 579]

2 Dec 2017 20:12:22 QLab: Warning: audioDeviceDidDie: *nil description*

I hope someone can make some sense of this and can provide some potential theories and/or answers. What is baffling is the inability to recreate the problem.

Thanks a bunch

Craig

[Chris Ashworth]

Hi Craig,

The audioDeviceDidOverload message means that QLab was not able to deliver audio data to the driver in time for the rendering deadline, and typically reflects a CPU bottleneck. (i.e. “the CPU was delayed long enough that when the audio driver asked for samples, it didn’t get them in time, even though they were available in the RAM buffer.)

The more concerning log is audioDeviceDidDie, which means the device was either unplugged or malfunctioned in a manner serious enough to look like it was completely disconnected. If that shows up, it’s bad news. Items to check include: bad or loose cables, whether the audio device has a more recent driver, etc.

Best,

Chris

[stevenso...@gmail.com]

Hi Chris

Thank you for the quick reply. Could audioDeviceDidOverload not trigger due to audioDeviceDidDie (it happens at the exact same time - 20:12:15) along with USB sound assertion (not sure what that means?)

The device was definitely not unplugged, it could be a faulty cable but that doesn't explain why it happened in the same cue both times.

(NOTE: Just before posting this I have remembered that it actually wasn't the same cue, but rather the second cue of the show - which happened to be different cues on these occasions)

I am not convinced there was a CPU bottleneck as there seems to be plenty left during my testing at home. Is there a way to log such bottlenecks if it happens again?

I can try a different cable but the sound device is class compliant and does not use a driver so I can't do anything about that.

If I were to make the buffer larger, would that send it out of sync with other cues that have been set based on time or would they just wait until the audio starts?

We have two shows this weekend, I will try that with a new usb cable and 4.1.6. If we still have a problem then I will roll-back to a version where I know it worked (I don't really update unless there is a new feature or I have problems)

Thanks

Craig

[Chris Ashworth]

Hi Craig,

If the audio device “dies” then no further overloads will happen; any audioDeviceDidDie message in the logs is a critical error; if you see that it’s bad news.

Changing the buffer size of the device might help with an overload (and would not affect the programming of the cues), but that is less important to troubleshoot at this point than the audioDeviceDidDie, which indicates a larger problem.

For most shows you shouldn’t need to change the device buffer size from the default (typically 512).  

Here are some other things you can explore to prep the computer for the best playback:

https://figure53.com/docs/qlab/v4/general/preparing-your-mac/

Cheers,

C

[Mark Burke]

Chris!

Biz here. I’ve been having the same issue lately with our motu. I get an audio dropout (which is really bad for a dance show). Do you think it’s a motu issue ? Qlab issue? Or OS issue? I’ve totally wiped the computer to its default, did all the steps in a computer prepares and only have qlab and the motu drivers installed. It’s becoming more frequent but never at the same point in the show. The error is audio device did overload.

On another note, I believe the issue I had with 4.2 was I tried to open a show file that was before 4.2. But I do have some feedback for some upgrades. It would be great to see the wave form attached to video so I can line it up better. Right now I can only do this my playing and then pausing, then I can align. Also when you zoom in it would be great to be abke to do it from the point the playhead stopped. Right now when I zoom it goes to the top of the stack, becomes a little frustrating to have to keep zooming and scrolling. Anyways thanks man!

Best!

Biz

[stevenso...@gmail.com]

My problems went away after replacing the audio output device.

[Chris Ashworth]

Hi Biz,

The audioDeviceDidOverload message means that QLab was not able to deliver audio data to the driver in time for the rendering deadline, and typically reflects a CPU bottleneck. (i.e. “the CPU was delayed long enough that when the audio driver asked for samples, it didn’t get them in time, even though they were available in the RAM buffer.)

i.e. this usually means computer is doing too much work and can’t keep up.

[Chris Ashworth]

Hi Mark,

It is unlikely to be related to the audio device, although it can’t hurt to test a different one if you have it.

An overload is a CPU bottleneck; the computer is generally doing too much work.

Troubleshooting typically involves identifying what extra work is happening when the overloads happen, and reducing that load.

We can help you with that process, and the easiest way to do that is via the in-app “Contact Support” menu item from the help menu. Also check the box “include console logs” 

Best,

Chris

Chris!

Thank you for the quick response. Do you have any suggestions/solutions to fix this issue? Thinking about changing audio interfaces to the Focusrite Scarlett. Again the computer was completely wiped and prepared. 

Thanks again!

Biz

[stevenso...@gmail.com]

While it might usually be the case that it is a CPU bottleneck, that was not the case for me. My problem was the audio device and replacing it made the issue to disappear.

So, I had overload messages that were definitely nothing to do with a CPU bottleneck. It worked fine for months before and then works fine currently after replacing the audio device.

It is certainly wrong to dismiss the idea of it being a faulty audio device and I would try a different one to see if that solves your problem.

[Chris Ashworth]

Hi Stevensoncraig999, 

If Biz has another device already available, then I agree it can’t hurt for him to give that a try. (Or to try the built-in output which is always available.)

But for folks who are reading this thread in the future, I’d caution that buying a (possibly expensive) new audio device is not a general solution to the issue of overloads.

Sometimes changing audio devices is indeed a useful (and sometimes critical) step, but in terms of troubleshooting this particular log message there are other issues more likely to contribute to this condition, and troubleshooting those first is a good place to start.

One example that could look like it’s an issue with the audio device, but is not inherently an issue with the audio device, and might be resolved without changing devices is:

If an audio device has many output channels, and a workspace is playing many low-channel-count files simultaneously, this introduces more CPU work than is necessary when routing the cues to the audio device.  In this case it could be possible to combine 1 and 2-channel files into a single multi-channel file to use the CPU more efficiently. In this case, changing to a different audio device with fewer output channels could also reduce the CPU load by reducing the size of the matrices in the audio signal path, but that is not so much an issue of the device itself, but a consequence of how it is being used. (Not saying this happened for anyone here, but giving it as an example.)

Best,

C

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: https://twitter.com/Figure53
User Group Code of Conduct: https://figure53.com/help/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/836d9fc0-69e1-4e91-814f-693140d5f0cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sam Kusnetz]

Craig 

Occurrences of the “audioDeviceDidDie” message can indeed cause other errors to appear. Our general rule is that if you see “audioDeviceDidDie”, you cannot trust the validity of any other errors since once the audio device is unavailable, the computer kind of says “well now I just have no idea what to do.”

The overload messages you got very much did have to do with the CPU, which was working like hell to send audio to a destination that no longer existed.

Additionally, the Scarlett unfortunately has a history of problems like this which I have been tracking for years but have not been able to discover any more details about. Focusrite’s other gear works fine; I’ve used their Safire Pro line for years and never had one problem, but there’s something about the Scarlett that just misbehaves.

Best

Sam

--

Sam Kusnetz | Figure 53

http://qlab.tips | http://gobutton.tips

s...@figure53.com

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/etPan.5b854409.7b87b4c3.3318%40figure53.com.