Recorded Tracks not synchronised

[Johannes]

Just to add: I don't think the difference in file length has anything to do with dropped packets, at least not in our case. The remote file is always shorter by about half a second, I assume because the recording start and stop is not accurately synchronised.

Correction: The remote file is always _longer_ by about half a second.

[SteveW]

I just had another look at the tracks in my DAW--the files are the ogg files whose names are prefixed with 'LocalTrack'. I'm taking the rhythm guitar track from participant A and the bass track from participant B, as these are quite easy to synchronise precisely. The first song starts at about 1min 6sec and I am aligning the tracks as exactly as possible (by eye and ear) at this point. The second song starts at 11 min 33 sec and, by that stage, the bass is noticeably ahead of the guitar.

The final track of the session that includes both instruments starts at 1 hour 18min 13sec for the bass and 1 hour 18min 15.5sec for the guitar. So, by this stage, the tracks have drifted apart by about 2.5 sec!

Curiouser and curiouser!

[Johannes]

You can get JamKazam to keep the WAVs, there is a setting for that somewhere.

My suspicion is that your soundcards/interfaces are not very well synchronised in themselves, perhaps they have unreliable clocks. A drift of 2.5 seconds is not normal, and certainly not what I get. Whether this is due to internet or interface is another question.

We are both using MOTU interfaces, though different ones. As I said, I don't notice drift, if I manage to the beginning well synchronised the final chords are still together, though I admit I haven't checked the exact synchronisation at the end.

We are recording extensively at the weekend, and I may be able to examine the resulting files further. Perhaps there will be drift, too, who knows, but it is small.

[SteveW]

The rhythm guitar player (player A) is using a Focusrite scarlett 2nd gen interface with a Mac, 48kHz sample rate and 1ms frame size.

The bass player (B) is using Windows, Behringer interface, 48kHz and I think a 5ms frame size.

There were only 3 of us playing in that session. Player C was on lead guitar which is a bit harder to synchronise but there is a very good synch point at the start of the first song and another partway through the final song at about 1 hour 20 min 46 sec. By this time player C was about 150 ms ahead of player A. Player C was using Mac, Focusrite 3rd gen, 48kHz, 1ms frame size.

All were using wired ethernet, no video, no other apps running on PCs.

As far as I know the LocalTrack files are recorded locally at each person's PC, then distributed by the JK File Manager so I presume they are a not affected by network performance, unless this gets so bad that buffer overruns occur. But maybe that is what is happening to us!

[Zlartibartfast]

I'm curious about what type of network connection is at play with each session member - P2P, or ARS?

I ask because I have been in a few session where the synchronization between 2 players on PTP was tighter than players on ARS.

There may be a relation$p between the computers' clocks and track synchronization (I'm not referring the interfaces' clocking scheme, since they are modern and the only digital link is between the interface and the host PC). Keeping time on the internet is a really big deal, and NTP is the most common protocol. for Mac users, setting time using NTP is easy because Apple runs their own NTP servers. For Windows and Linux users, you have to specify your NTP server(s).

https://www.pool.ntp.org/zone/north-america.

I'm speculating this might help, I don't know for sure.

[SteveW]

I'm curious about what type of network connection is at play with each session member - P2P, or ARS?

I ask because I have been in a few session where the synchronization between 2 players on PTP was tighter than players on ARS.

There may be a relation$p between the computers' clocks and track synchronization (I'm not referring the interfaces' clocking scheme, since they are modern and the only digital link is between the interface and the host PC). Keeping time on the internet is a really big deal, and NTP is the most common protocol. for Mac users, setting time using NTP is easy because Apple runs their own NTP servers. For Windows and Linux users, you have to specify your NTP server(s).

https://www.pool.ntp.org/zone/north-america.

I'm speculating this might help, I don't know for sure.

We all have peer-to-peer selected. We all live within about 10 miles of each other so I would have thought that was likely to be the best option.

I'lll have a look at some of our other session recordings to see if there is any obvious pattern, although I am sure that we always experience drift between participants' tracks. I always do DAW mixes of at least some of the songs we do in a session and it is always necessary to synchronise the tracks for each song separately--and sometimes during the course of a song. Occasionally there is a song with so many synch problems that I simply cannot get a good mix, even after a lot of chopping and synchronising segments of audio.

[Johannes]

Ok, I have to correct myself: There is drift in the recording. I had to resynchronise the recording every few minutes. I don't think it is a consistent value, so I assume that perhaps dropouts are in fact the problem, although they shouldn't really happen (and didn't happen on my side, at least according to the drop out counter). The remote track was "faster" by about 10ms/10min. For our purposes it was enough to do a correction appr. every 5 minutes. Not ideal, but just workable.

The offset at the beginning is pretty consistent between 250 and 260ms.

Otherwise we had very good latency times these two days, around 22ms from Berlin to Prague. We could have got slightly better by using a smaller frame size, but in tests this led to dropouts, probably because our computers are not the fastest.

[Johannes]

Another update:

In our second recording the drop out problem was more severe, and I am now convinced that this is the reason for the drift. This is in the WAV files recorded locally, so I assume it is probably the computer setup of my partner. We didn't realise there was a problem so we didn't correct it. I assume it is perhaps less a problem of JamKazam, and more of a problem of general computer setup.

When I did a recording with someone else who had a powerful computer we noticed neither a drift nor a drop out problem.

[Dimitri Muskens]

Another update:

In our second recording the drop out problem was more severe, and I am now convinced that this is the reason for the drift. This is in the WAV files recorded locally, so I assume it is probably the computer setup of my partner. We didn't realise there was a problem so we didn't correct it. I assume it is perhaps less a problem of JamKazam, and more of a problem of general computer setup.

When I did a recording with someone else who had a powerful computer we noticed neither a drift nor a drop out problem.

>>>
In itself good news! (not so much for the situation with your partner)
Thanks for reporting.

D./

[Wester]

Hi all,

I set up Logic Pro X  to JK .
Everything does work well except that I have some crackeling especially when I run a loop - of drums or other software instrument. Input Jitter red and output Jitter Yellow/red/green...
My CPU is normal and my buffer size is 128. 48 Khz
My audio interface input settings on logic is a RUBIX44  with Blackhole audio output.
Does anyone have a suggestion?


Thanks for feedback ,