Gap in show while playing

Guillaume Rousseau · Sun Jun 30, 2013 2:36 pm

Hi,

I am trying to use shows, seems very great, but it seems there is a growing gap between cursor position and music I am listing, and it seems it is growing with time. I can move the cursor on the position I want, it will always start playing music at the right time, but a gap is growing with time playing...

Using 4.4.0 beta 1 or the last stable 4.3.3, same problem, under ubuntu 12.04, amd64...

It should be strange if it only happens to me... I can make a video with music and waveform for those who don't believe me

Thanks

Massimo Callegari · Sun Jun 30, 2013 3:04 pm

Already discussed here:
http://sourceforge.net/p/qlcplus/discus ... /1be8e988/

Can you please try using WAV files and different sample rates ?

Guillaume Rousseau · Sun Jun 30, 2013 3:35 pm

Sorry, I should have search better before

I tried wav, flac, wav in 44k, 22k, 16 or 32bits, still a gap.

But if the waveform is good, it should not be a very big problem, it should be just easier without this problem. I saw you talked about CPU consuming to move this yellow bar, should it be possible to try without bar moving to see if sync is good without it ? Or maybe it should be possible to modify the refresh rate ?

I tried to lunch music and switch to an other tab, I see it was less cpu consuming, but while trying to switch to show tab about 20 seconds after, qlcplus consumes 100% cpu, freezes (switch to grey), music still playing... successfully switches after about 1 minute waiting for it, switching to grey a few seconds after. The song has finished for about 7 minutes, qlcplus process is still at 100% and still on grey, I will force close it.

Guillaume Rousseau · Sun Jun 30, 2013 3:51 pm

Something not directly relating to gap problem, I should like a kind of tap function in show, while building them. I mean listing to the music, and pressing a button to add marks all along the music, because we know we have to use each mark to change something to the show.

Massimo Callegari · Sun Jun 30, 2013 3:59 pm

To avoid CPU consuming, create a button on the Virtual Console and attach your show to it. Then play it from there.
I guess you're using the waveform to sync music and lights, right ?
Maybe it's just a rendering issue of the waveform itself. If it's not extremely precise it might cause this behaviour.
I'll have another look into it, even though I was pretty sure I did it right.

Guillaume Rousseau · Sun Jun 30, 2013 4:22 pm

I had a look, waveform seems good, I compared it with the one generated by Mixxx.

I just tried the button, but... the gap is still here between what I ear, and the lights. Waveform vs time is good (compared to mixxx waveform/timeline), but time vs sound seems not good... and this is still a growing gap, I mean on the begging of the show, it is quite sync, after one minute, the gap is about 6 seconds.

Guillaume Rousseau · Sun Jun 30, 2013 4:27 pm

On my computer, the gap is about 3 seconds after 46 seconds, don't know if it depends on computer's velocity...

Massimo Callegari · Sun Jun 30, 2013 4:45 pm

Ok, just tried a 3 minutes 120bpm click generated with Audacity on a WAVE 44100Khz, 16bit.
Waveform preview is fine when zoom is 1:1. Other scaling is fucked up, but this depends on how Qt scales a bitmap. Except this, playback is fine even when resuming.

Now I am wondering another thing. A time shift makes me think of a sample rate conversion somewhere. If we agree the audio source is 44.1, then there might be a conversion on the audio card output. So if ALSA thinks it's running at 44.1 and your audio card works at 48Khz, then the shift might happen.
QLC+ tries to set ALSA at the sample rate of the source audio file, but if this rate is not supported by your audio card, there is no message informing you. (except for a debug message that you can't see on a released version)

Right now I'm on a laptop with a crappy integrated sound card, but I can try with my M-Audio Fast Track Pro which works at 48Khz.
Which audio card are you using ?

Massimo Callegari · Sun Jun 30, 2013 5:05 pm

I've added another track which turns a PAR 500ms on and 500ms off. Total of 180 steps. Played perfectly for 3 minutes.
Here's a screenshot

Guillaume Rousseau · Wed Jul 03, 2013 4:32 pm

Massimo, could you send me your audiofile, or, if you can, audio file and qlc file, to compare to my computer and check if it is a problem with the computer, or linux, alsa, etc.

Thanks

Massimo Callegari · Wed Jul 03, 2013 10:08 pm

Here it is

Chris Moses · Fri Jul 12, 2013 11:56 am

Tried your demo files on my Mac here and it goes out of sync as it plays... I guess it's something else that is causing the desynchronisation.

Massimo Callegari · Fri Jul 12, 2013 12:26 pm

Then I suppose it's something around the PortAudio renderer specific for OSX.
I'll have a go with it on Linux and see what happens.

Massimo Callegari · Sat Jul 13, 2013 10:12 am

I've done the test using PortAudio in Linux and it worked perfectly.
This confirms that the QLC+ code is working properly but leads to something worse.
PortAudio is just an audio framework which expose a generic layer over a native audio system. In Linux it relies on JACK or ALSA, in Windows on DirectSound or ASIO and on OSX (I think) it works over CoreAudio.
This means that my audio test on Linux works because PortAudio works fine on Linux audio systems. Probably the OSX port is not as good as Linux's, thus the out of sync issue.

Hopefully this afternoon a friend will come over with a MacBook and I'll do the test again.

Massimo Callegari · Sun Jul 14, 2013 1:53 am

I've done the audio sync test on a MacBook from a few years ago (I think it's a core 2 duo) with Snow Leopard on it.
All went fine. I've used a QLC+ version with a couple of changes. Maybe those are the key. I share it here for you to try: https://dl.dropboxusercontent.com/u/410 ... _4.4.1.dmg

Please let me know your results

Rowan Deppeler · Mon Jul 15, 2013 2:07 am

Just confirming what Massimo found.
Building from the latest sources and running the audioSync test (without any changes), everything appears to stay in sync on both Mountain Lion (10.8) & Snow Leopard (10.6)
For interest's sake, I re-saved the wav file as an mp3 and substituted that in the same show. Re-running produced the same results without apparent loss of sync.