DROPOUT (audiodevicedidoverload)

[Pirates Adventure]

Hi everybody.

Last year I had a lot of problems with dropouts and this message in the log: AudiodeviceDidOverload

Well, I had a MOTU Traveller, a 16gbRAM imac, 7200 RPM hardisk.... was enouht, i think, for only shoot audios.

Ok. This year we changed to a new imac, 3.1ghz Intel Core i7, 16gb RAM and a SSD hard disk. We changed to a RME Fireface802, plugged via USB.

Everything looked ok.... but yesterday night.... DROPOUT AGAIN!!!!

I'm really lost.... I'm only shooting audio files and some MIDI orders.

The buffer is at 512. Is better up or down that parameter?

What can I trie to do?

I did everythinh Chris said to do for prepare, execute and troubleshoot the imac....

Help....

[Chris Ashworth]

Hello Pirates Adventure,

First: The “audio device did overload” message typically happens when there is a CPU bottleneck.

Second: since it’s a new system we shouldn’t assume that we know the cause this time. Please contact us via QLab from “Help” —> “Contact Support” and check the box to include console logs. That way we can review the current information to learn what is happening, which may or may not be related to what was happening before.

Best,

Chris

[Pirates Adventure]

Hi Chris.

The log it's send. Thanks!!! 

[Andy Lang]

For those following along at home, we seem to have tracked down the problem with Bernat's setup, pending confirmation from his next show.

It's a common enough problem that I wanted to post it here, as a warning for anybody who sees it. As some of you know, in the QLab menu, there's a Preferences setting with a few global preferences for QLab. One of these allows you to set how verbose the debug logging QLab does is. It is very important to NEVER change this from the default setting of 0 unless we tell you to, and, if we do, to only change it long enough to send us the logs we requested, and then immediately reset it to 0 so you don't forget.

The more verbose logging levels log a LOT of data and, while important in some situations for troubleshooting, this causes a significant increase in the workload for QLab, and becomes somewhat of an example of Heisenberg's observer effect. The act of logging the data to try to find the problem can, in and of itself, cause its own problems. So far, this seems to be what was happening in Bernat's case.

As long as we're talking about logging, I should add one more suggestion/request that's not directly related to this case. If you do need to send logs in to us, verbose or otherwise, please always be sure to either submit them via QLab 3's support contact form, or send us the entire log, exported as a .log file, from Console. Please don't just cut and paste the small segment that you think is pertinent or, worse, send us a screenshot. We need to see the entire log to see the problem in context of what's going on with the computer as a whole. QLab doesn't run in a vacuum, and very often problems outside of QLab contribute to problems within QLab. Without the full data to look at, we can't help, and it just means that instead of getting you an answer right away, we have to email back asking for the rest of the logs, wasting time that you could be running QLab without the problem :-D

Best always,

Andy

On Fri, May 15, 2015 at 10:16 AM Pirates Adventure <tecnico...@gmail.com> wrote:

Hi Chris.

The log it's send. Thanks!!! 

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
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.
For more options, visit https://groups.google.com/d/optout.

[Pirates Adventure]

Thousands thanks!!

I will tell you if its going ok in the next running shows!!!  

[Pirates Adventure]

I have to say, for now, after 5 more shows, everything is perfect! I will let you know news!!

Thanks!!