Slow response on triggers.

[the.sound...@gmail.com]

Hello

Im currently creating a show where i need a sound from stage to trigger a sound cue in qlab.

I have solved this with a separate trigger interface. Alesis trigger IO. For some reason the que triggerd starts way to slow even though the que is loaded.

This is not acceptable since there is a loud echo effect from the real onstage sound from stage. They need to be as close together as possible to be accepted as one sound. 

I do realize that the usb trigger interface applies some delay but I have used the same interface on an pc with the same sound card  and managed to get real fast reaction times.

Even triggered  with a hot key it seems slow to me. Go also feels sluggish but not as bad.

About 150 ms or so. Im hoping for about 10 - 20 ms.

Is there anything I can tweak to make the go more responsive? 

If the que is loaded the go should be instant shouldn't it?

The audio is cut super tight.

Buffer set to 32 samples on a lynx aes 16e.

Qlab 3.0.8

Mac pro 3.2 Ghz quad-core

8 GB memory

OSX 10.8.4

Audio files saved on internal APPLE SSD SM512E  not on system disk.

Very best regards. 

Jesper Lindell

[Christopher Ashworth]

Hi Jesper,

On the face of it that all looks good.  I'd be curious to try the file on my end, if you wish to send it.  

For troubleshooting, try things like:

• Play out a different audio device

• Test with the keyboard or mouse, to reduce complexity at first

A 150 ms delay is much larger than the playback speed that QLab can provide.  It will typically be able to provide audio within a few milliseconds of triggering, so we're missing some piece of the puzzle.

-C

[the.sound...@gmail.com]

Hello again Chistopher.

Now I have done some testing with different sound cards, different midi interface and also a different computer all to gather, a mac book pro with SSD drive
With a digiram stereo sound card I performed a recording where I recorded the actual sound from me hitting the space bar and also me hitting a midi trigg. The audio from the sound card was played up loud and you can clearly measure the delay in a sequencer program between the go and the actual sound. I never got it below 100 ms

I would love to send you the show and the 2 audio recordings.

Please send me your mail address if this attachment does not work

Best regards.

Jesper

[Christopher Ashworth]

Hi Jesper,

Thanks for sending the workspace.

The time it takes for a pre-loaded audio cue to "attach" to the audio device (i.e. be completely set up and ready to provide audio) is a somewhere between 1-3 milliseconds.

However, the audio will not begin delivery until the top of the next "pull" cycle from the audio driver.

The 100-150 millisecond delay you're measuring is, I think, the time QLab spends waiting for the audio driver to request more samples.

e.g. if your device buffer is set at 512 frames and is running at 44100 KHz, that is about 0.012 seconds you might have to wait until QLab can deliver the first samples of your cue.

If you reduce the buffer size of the device (under QLab --> Preferences) you can reduce the delay.

Note that the tradeoff here is that your system will be more susceptible to glitches, since the audio driver will be asking for samples much more frequently. You'll need to make sure the system is tuned well so that it can smoothly provide audio as quickly as possible.

Hope that helps,
Chris

[micpool]

That should still make the total wait 15ms which is far shorter than the 100ms Jesper is reporting.

Mic

[Chris Ashworth]

Ah, indeed, I got the conversion wrong in my head.

Well, Jesper, what I can say is that using your workspace I measured a few milliseconds plus the device buffer. I did this by turning on log level 3 and looking between the GO log and the "first frames read" log.

May be worth trying that approach?

(mobile)

--
--
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/groups/opt_out.
 
 

[the.sound...@gmail.com]

I have had a 64 sample buffer on all my tests so it could not be this.

I´ll try your thing with logging my GO:s.

Please also have a look at the 2 audio files included in the zip file where I have recorded the delay.

Best.  Jesper

[the.sound...@gmail.com]

Ok interesting

Using the log when Q-lab is recieveing the message go until I get the fist read make a delay of only 5 ms.

Is there any way to log the actual press of the space bar or the actual click of the mouse so that I can rule out any delays before Q-lab responds to any go command?

Im still have about 119 ms delay from the physical press to analog audio coming out of the sound card.

Best. Jesper

Den onsdagen den 14:e augusti 2013 kl. 01:13:54 UTC+2 skrev Christopher Ashworth:

[Chris Ashworth]

(mobile)

On Aug 14, 2013, at 4:02 AM, the.sound...@gmail.com wrote:

> Ok interesting
>
> Using the log when Q-lab is recieveing the message go until I get the fist read make a delay of only 5 ms.
>
> Is there any way to log the actual press of the space bar or the actual click of the mouse so that I can rule out any delays before Q-lab responds to any go command?

That's basically what the GO log already is.

>
> Im still have about 119 ms delay from the physical press to analog audio coming out of the sound card.

Have you tried a different output device, to compare?

Also, what exactly is your measurement setup?

C

[the.sound...@gmail.com]

Yes. 4 different sound cards including internal and 2 different computers. 

Also, what exactly is your measurement setup?

I have recorded the audio of me hitting the space bar and then the audio coming out from a speaker directly connected to the analog out from a stereo sound card. There you can se the peak when the space is hit and then when the audio is played up. In the zip file above I have included the 2 audio files I recorded. Not Hi Fi but clear enough. If you put the file in a sequencer program you can zoom it down to milli seconds and messure the delay.

To me it seams like there is a delay between the space bar is hit and the command GO is sent.

So is there anyway I can log when the actual spacebar is hit and se what the delay is when the GO command is sent?

It would also be interesting to tweak the computer so that qlab get a higher level of prio in processes. Is there any way to do this?

Jesper

 

C

[Christopher Ashworth]

On Aug 14, 2013, at 7:34 AM, the.sound...@gmail.com wrote:

I have recorded the audio of me hitting the space bar and then the audio coming out from a speaker directly connected to the analog out from a stereo sound card. There you can se the peak when the space is hit and then when the audio is played up. In the zip file above I have included the 2 audio files I recorded. Not Hi Fi but clear enough. If you put the file in a sequencer program you can zoom it down to milli seconds and messure the delay.

To me it seams like there is a delay between the space bar is hit and the command GO is sent.

So is there anyway I can log when the actual spacebar is hit and se what the delay is when the GO command is sent?

This morning I added another log message to the first location that QLab receives an incoming event notification about the keyboard press.

It is a useful exercise, as it does show around .02 seconds that are spent providing visual feedback on the GO button (i.e. drawing it as it presses down) prior to the GO log message you have already seen.

Thus, that time would be added to the total. By my count that's only .03 or .04 seconds, though, not 0.1.

If I remove the call to route through the button, and just immediately proceed to the go command where the log message is sent out, the delay is less than a millisecond.

It would also be interesting to tweak the computer so that qlab get a higher level of prio in processes. Is there any way to do this?

I'm not aware of a way to do this.

-C

[Andy Leviss Lang]

> On Aug 14, 2013, at 7:34 AM, the.sound...@gmail.com wrote:
>
> I have recorded the audio of me hitting the space bar and then the audio
> coming out from a speaker directly connected to the analog out from a stereo
> sound card. There you can se the peak when the space is hit and then when
> the audio is played up. In the zip file above I have included the 2 audio
> files I recorded. Not Hi Fi but clear enough. If you put the file in a
> sequencer program you can zoom it down to milli seconds and messure the
> delay.

What are you using to record this? Where is the microphone in relation
to the space bar, and in relation to the speaker; how far away is it
from either? What audio interface are you using to play back your
audio to the speaker, and what is it's D/A latency? Is there any other
processing between the audio output from that interface and the
amplifier, or are they directly connected?

All of these are potential sources of latency that would be present in
the audio output and not in the acoustic sound of the spacebar being
hit, and which would be after QLab and not within it's control.

-Andy

[Rich Walsh]

I thought I'd test this as I have built and used many, many QLab systems and never encountered an issue like this: confident that even with the audio on my highly-fragmented, overfull, 5400rpm internal system drive QLab would not feel sluggish.

It doesn't (QLab 3.0.8 under Mac OS X 10.8.4; built-in output, default buffer). No matter what I set the system sample rate to, either (I note that the test audio is at 48kHz).

However, if I record the process as you have described – even using a separate field recorder to rule out any delay caused by the recording software – I do indeed measure a space between the transient of my hitting the space bar and that of the sound playing… c100ms in my case, and yet it doesn't feel sluggish to me (and I have operated an extremely fast show packed with visual cues on this very laptop).

Interesting: to me QLab is behaving as expected, but measurements suggest it's adding 1/10s to my 1/5s reaction time. No-one's complained yet though…

Incidentally, the same exercise in Live yields 60ms on this laptop. I have positioned my mic halfway between my keyboard and the speakers, and used a spike to test.

Rich