Jack sync problems

Ardour 8.2.0

This manifests itself in at least 2 areas:

  1. If I enable JACK, Go to the beginning of my song and hit record the actual recorded region starts at 00:00:00.042 (as seen by right click on region Properties) . If I disable JACK and do the same thing the recorded region starts at 00:00:00:000.

  2. If I enable JACK and sync a Hydrogen song with only kick drums on every quarter note then make a midi trick with quantized kick drums on every quarter note and play them together I hear 2 distinct kicks per beat. If I delay my midi track to start at 00:00:00.042 the two tracks play together.

Any ideas?

By disable JACK do you mean you use the ALSA backend, or that you use JACK for audio, but do not sync to jack-transport?

Have you calibrated the system audio latency when using jackd? I guess that suggests an additional question, are you using jackd or pipewire-jack?

Sorry I should have added that I’m using AVLINUX (AV_Linux_MX_Edition-21.2.1_ahs_x64) but have upgraded from their version of Ardour to Ardour 8.2.0.

When I said “disable JACK” I simply meant clicking on the JACK button (upper left) so it turns into “Int.”. There was I time, in previous versions of Ardour, when I would start JACK through qjackctl but, if I understand correctly, all this is now taken care of directly in Ardour. Nevertheless ‘ps aux |grep jackd’ reports that jackd is still running in the background irrespective of where the JACK button displays “JACK” or “Int.”

I have calibrated the system audio latency when using jackd for my audio hardware. It found a delay of 26 samples. Unless I’m missing something, the problems I’m seeing should be independent of my audio hardware calibration as Hydrogen is running on the same physical machine and that the region start phenomenon I described originally is also seen if I just try to record a new region using input from another track.

I am using jackd not pipewire-jack.

Thanks

That would be more clearly described as changing the transport source clock from JACK to Internal. It does not change the state of the jackd audio server at all, and it does not modify the audio backend connections at all, it just changes the source of the transport clock.

I believe that is correct, changing the transport control should not change the audio latency compensation.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.