Re: [QLab] Audio skipping back about .5-1 seconds during playback

[Chris Ashworth]

Hi Steve,

The biggest puzzle about this is, unless I'm forgetting some obscure corner of the code, there is, to my knowledge, no way for QLab to behave this way.

Quite the contradiction since apparently it has!

But if no looping is enabled I don't know of any way thy audio can be delivered once and then delivered again a second time. Once it's "out the door" it doesn't exist any longer in QLab's buffers, so it couldn't be sent out again.

Thus I am wondering if there is something deeper going wrong, and would like to see console logs for the machine. Could you send these to me at sup...@figure53.com? Also a copy of the QLab workspace file.

One other possibility: is it possible that the audio delays/drops out for a second but does not actually rewind and play the same bit again?

Thanks!
Chris

[Steve Sensenig]

Thanks for the prompt reply! I can't get the console log off that machine easily, but I did find the following three entries referencing the track in question during last night's show. It looks like you might be right about it actually pausing. It is hard for me to tell live because there is so much going on live and I don't hear the click or tracks consistently at every moment. What does this tell you?

WARNING: Dropped xxx audio frames (requested 512 frames)

The first error dropped 376 frames and the other two times dropped all 512 frames.

Does that info help at all?

steve :)

[Lucas Krech]

You sure it's not the ghost of the soldier in the basement?

-L

Lucas Benjaminh Krech

Lighting and Video Artist

www.lucaskrech.com

646.263.8439

gChat: lucaskrech

Twitter: lucaskrech

Skype: lucaskrech

- - - - - - - - - - - - - - - - - - - - - - -

"Dancers live in light like fish live in water"

~Jean Rosenthal

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab

Follow Figure 53 on Twitter: http://twitter.com/Figure53

[Chris Ashworth]

Hi Steve,

A pause or dropout is, I think, much more likely then a rewind. In that case there are quite a lot of things that can lead to dropouts. The most common reason is if the computer is having trouble keeping up. Things to consider or check:

- What is the speed of the hard drive where the audio files are stored?
- What is the CPU load of the computer during the show? During the time of the dropouts?
- How many simultaneous cues are playing at once?
- Is spotlight disabled for the computer?
etc.

[ra byn (robin)]

On Sat, July 7, 2012 6:43 pm, Steve Sensenig wrote:
> WARNING: Dropped xxx audio frames (requested 512 frames)
>
> The first error dropped 376 frames and the other two times dropped all 512
> frames.
>
> Does that info help at all?

What audio device?
What sample rate?
Audio coming of the internal drive or external?
Power saving features disabled on the Mac?
Does it happen if you let the rig sit?
Does it happen between cues with a wait?
Does it happen everytime in the same place in the cue list?
Etc...?

The more information, the more likely the list is going to be helpful.

ra byn

[Steve Sensenig]

Lucas! Great to run across you again! We did some renovations to the theatre this year and I am convinced that Porterfield is not happy with them, so while not the soldier, I think you are on the right track ;)

[Steve Sensenig]

Christopher, thanks for the follow up. I will try to get you more info. I won't be back to this show for a few days, but will check all these details when I get back in the pit again.

[Steve Sensenig]

And reading my previous message would have shown that I've already conveyed some of that information, Ra. I'm brand new to QLab and these issues, so I don't necessarily know the answers to all of these questions, but am trying to answer Christopher's requests for information. Thanks for your warm welcome anyway.

[Keith Smith]

On 8 Jul 2012, at 02:01, ra byn (robin) wrote:

> On Sat, July 7, 2012 6:43 pm, Steve Sensenig wrote:
>> WARNING: Dropped xxx audio frames (requested 512 frames)
>>
>> The first error dropped 376 frames and the other two times dropped all 512
>> frames.
>

> What audio device?
> What sample rate?
> Audio coming of the internal drive or external?
> Power saving features disabled on the Mac?
> Does it happen if you let the rig sit?
> Does it happen between cues with a wait?
> Does it happen everytime in the same place in the cue list?

Given that this appears to happen quite infrequently I am less inclined to suspect the above and more inclined to suspect other things that can steal time and disk at "random" moments. For example:
* Spotlight kicking in
* Software Update doing an update check
* Another app, running at the same time, doing something (e.g. Mail checking for email, Dropbox doing an update, etc).
* Lion (you, as in the OP, haven't said which version of the OS you are running) "helpfully" choosing that moment to save a new version of a file that's open in another app

I think this is external to QLab. If this is a big, multi-channel, high data rate, PCM file, it might not take that much interference for the system to drop a few frames and then drop a few more while it re-syncs.

That said, if you are more interested in avoiding the problem than in chasing down the exact cause, you'll probably fix this by making sure there is nothing else running on the machine, turning off extraneous services (like Spotlight), and moving the WAV file to a separate external disk.


Regards,
Keith.

[Paul Gotch]

On 8 Jul 2012, at 18:24, Keith Smith <keith...@keiths-place.com> wrote:

> , turning off extraneous services (like Spotlight),

There is a problem with turning off spotlight, by placing '/' in the privacy options. Apple's App Store update mechanism relies upon spotlight metadata. If you turn it off App Store, and therefore in 10.8, security updates won't work.

-p

[Chris Ashworth]

Interesting point.

However, I'd argue this is still preferable to having a Spotlight kick in indexing your drive in the middle of a show.

-C

[Keith Smith]

Do you run security updates from your 'show' user account?

I wasn't advocating turning off Spotlight (and everything that is useful) in every user account - just the one that the show runs in.


Regards,
Keith.

[Paul Gotch]

On Sun, Jul 08, 2012 at 01:47:18PM -0400, Chris Ashworth wrote:
> However, I'd argue this is still preferable to having a Spotlight
> kick in indexing your drive in the middle of a show.

Oh probably but it's another problem to contend with if you don't have
the luxury of a dedicated machine for shows.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Paul Gotch]

On Sun, Jul 08, 2012 at 08:17:00PM +0100, Keith Smith wrote:
> Do you run security updates from your 'show' user account?

That doesn't matter spotlight is a system service and if a directory is
indexed or not is part of the metadata stored in the directory itself
it's not a per user setting. Adding / in one account, which would need
administrative privileges as it would need to write into /, would
disable it for all accounts.

Re-enabling spotlight will cause the disk to re-index which will take
some minutes and cause you Mac to get hot and bothered.

All this is fine if you have a separate show computer and it's treated
as an embedded box and only updated at the end of the season. However
not all of us are in this position and the show ends up getting run
from the designer's laptop much of the time.

[Steve Sensenig]

All: Thank you for all of the input.  I must clarify one thing that really interferes with this discussion--I am the Music Director playing/conducting/running this show, and while I created the audio files and set up a lot of them in QLab, I do not know much about the computer it runs on because it was set up for me, and is managed, by the Sound Designer.

When I show up to perform a show, sound has already booted up the computer, loaded the show for me, and done a line check.  I simply come in, check to make sure I'm on the first cue and that it's loaded into RAM (by pressing "L"), get my keyboards on the right patches to start the show, and hit "GO" when appropriate Stage Management turns my cue light off at the top of the show.  And then I hit "GO" many times throughout the show when appropriate, while playing, changing patches on my keyboard, conducting, trying to follow the click track, and quickly think of solutions for when things go wrong!!!  That's why I don't want tracks pausing or dropping out! hehe  ;)

I'm sorry I can't answer all the other questions yet about Spotlight, which user account is running the show on the computer, etc. etc. etc.  I'm technologically VERY proficient, but in this case, I'm flying blind on a lot of this information because I'm just using the laptop that is provided as is.

I will say that I know the computer is not on an network connected to the internet (it is on an internal wireless network that ONLY exists between the Sound Designer's computers and the show computer so that he can take control of the screen during tech and work on aspects of the QLab show while we are not using a track.  And the computer I am using DOES stay dedicated to this show for the entire three-month run and stays installed in the pit between shows, albeit turned off and closed up (and covered up since the pit cover gets installed or uninstalled every time we rep into or out of this show).

Other than that, as I mentioned above, I'll have to get back to you guys with answers to a lot of these questions that I just do not have the answers for.

[Mike P]

It sounds like you would be most benefited if your Sound Designer could join the conversation. S/he has set up a 'turnkey' system for you which is great, but many of the answers you are looking for will require input from someone who is responsible for how the computer is set up. Things like whether or not Spotlight is active, specific equipment specs, file formats, what other resources are enabled that could be dragging things down... If nothing else, maybe they can get a full copy of the Console Log to ship off to Chris so he can see more about what's going on.

Side note: The practice of connecting to a system from another for remote control is not uncommon, but does have significant overhead. I personally think using the wireless network to do this is even worse and always run a hard CAT 5e or 6 line between my machines which is simple to do so long as you have a path to run it. I've gone as far as 160 feet away using an Ethernet hub to boost the signal. Is that link still active when you are in performance and if so can you try having it disabled? I don't know that this would help you at all, but it's something to consider. Maybe the bigger brains on this list can comment further.

Mike Post
(601) 307-8657
mdp...@mac.com
http://mdpostdesign.com

[Jeremy Lee]

I have, in the past, had QLab hiccup while I'm using screen sharing, but it went away once I stopped.  Dedicated hard-wired KVM extenders are definitely preferred.

On Jul 8, 2012, at 11:07 PM, Steve Sensenig wrote:

I will say that I know the computer is not on an network connected to the internet (it is on an internal wireless network that ONLY exists between the Sound Designer's computers and the show computer so that he can take control of the screen during tech and work on aspects of the QLab show while we are not using a track.  And the computer I am using DOES stay dedicated to this show for the entire three-month run and stays installed in the pit between shows, albeit turned off and closed up (and covered up since the pit cover gets installed or uninstalled every time we rep into or out of this show).

-- 

Jeremy Lee

    Sound Designer, NYC - USA 829

        http://www.jjlee.com

[Christopher Ashworth]

Hi Daniel,

It's very unlikely that the audio is skipping backwards in time, unless your device driver is somehow buffering that much audio and skipping backwards at that level. Once the audio is out of the buffer in QLab, it doesn't hold on to it, so that can't happen at the QLab level.

The most likely scenario is you're getting a dropout rather than skipping backwards, and then the audio is resuming where it stopped, or something similar. This can be caused by many reasons, but the most likely is the disk gets bogged down for some reason and can't keep up. If the disk is slower (e.g. 5400 rpm) or something begins using it heavily, or both, this can cause audio playback to be affected.

Things to check:

System energy saver is set to off, so the disk won't go to sleep.

Spotlight is turned off for that disk, so it won't engage and begin heavy disk usage.

Other applications are not running concurrently with QLab.

Best,
Chris


On Dec 1, 2012, at 11:53 PM, Daniel Warneke <daniel....@gmail.com> wrote:

> Hello everyone,
>
> I found this forum while searching for a solution to the problem very similar to the one that Steve explained. Has anyone encountered any new developments as to the cause? It has happened to me twice thus far in the run over a span of maybe 20 - 30 performances, each time in a different location, but only while playing a single 2-channel .wav at 24/48k
>
> We run a dedicated mac mini operating the latest update for Snow Leopard. Interface is a Saffire Pro 40, which has its own connection issues occasionally from a miscommunication between chipsets (I think, or at least what I've pulled from research).
>

[ra byn taylor]

This is a long shot. Not even sure a Mac Mini has a motion sensor but if the mac mini is being bounced (due to LF content) or the desk / rack is being bumped / moved, you might be dealing with an issue I have from time to time when I'm walking around with my Mac Book Pro where the HD freaks out due to the motion sensor readings. Over on the Metric Halo user list, there have been engineers who had to resort to using SSD because they have these issues when set up to record in rock venues. 

I have a habit of walking around with headphones on while working with my recording sessions. It wasn't until recently that I realized that the faults I often experience are related to the internal motion sensor & the OS trying to park the heads to protect the HD. My next Mac will be an SSD equpped model for various reasons.

ra byn

[Keith Smith]

On 2 Dec 2012, at 15:37, ra byn taylor wrote:

> Over on the Metric Halo user list, there have been engineers who had to resort to using SSD because they have these issues when set up to record in rock venues.

I agree, this is a very real issue. Modern disks with spinning platters are very susceptible to disk vibration and you can have an immediate and measurable performance hit triggered by just about anything. A while back some engineers at Sun found that even shouting at a disk was enough to have an immediate performance impact.

I'm not kidding: http://www.youtube.com/watch?v=tDacjrSCeq4


This is why some of us get so anal about data rates and pipeline headroom.


Regards,
Keith.

[Daniel Warneke]

Truly interesting stuff.  Thank you so much for the support everyone.  We had another audio drop-out that was reported with last night's show.  Prior to this skip I've confirmed the proper settings on the hard disk preferences, disabled spotlight, and turned off any programs that activate on reboot.  The computer does live on a rather unstable shelf (the kind with the flat metal brackets and the wall track), and I know it vibrates.  I'll move the computer to a more stable location and report back.

Thanks again,

- Dan

[Jeremy Lee]

Something else I've had issues with is loading. If you fire a cue, and a huge cue follows it, it immediately starts loading. If its massive, it can halt playback for a moment. You can see if this is an issue by selecting the first cue, loading it, then playing it with the V key. This will not load the next cue. If it doesn't skip, but does in a regular/ linear cueing scenario, then you need to manually manage the loading of cues...

Jeremy Lee

- A thumb is a terrible speller. Please forgive my trespasses.

--