Recording offsets for Overwitch vs. main JACK inputs

[toupeira]

This is probably more of a support question, thanks for indulging me :)

I'm using Bitwig with JACK and Overwitch with a Syntakt, it works great but adds a latency of about 5ms when recording. I can fix this by setting the recording offset in Bitwig's Audio settings to 5ms / 240 samples, but then my other inputs from my main audio interface are recorded ahead as well.

This is probably something that needs to be supported in Bitwig, and I sent them an email asking if it would be possible to support individual recording offsets for different JACK input channels

But I was wondering how other people are dealing with this problem, maybe other DAWs handle this better? I also reduced the USB buffer length in Overwatch from the default 24 to 8, this shortened the delay by 1-2ms but I guess it's not possible to eliminate entirely.

Maybe there's also a way to add recording offsets inside JACK? As in, if I could delay my main audio interface by 5ms then I could also use the 5ms recording offset in Bitwig, and both my main audio interface and the Syntakt should line up.

[toupeira]

I found that it's possible to work around this using Bitwig's Time Shift device, I can set the recording offset there and bounce recordings to get the time-adjusted samples.

Closing :)

[dagargo]

Sorry for taking so long to answer.

Great that you found a solution.

Typically, applications and JACK allow to add offsets to deal with latency. That's why this feature was kept out of Overwitch.

[toupeira]

No worries, a week is plenty fast for an Open Source project! :grinning:

One thing that occurred to me is that a VST/CLAP version of Overwitch could probably report its latency to the plugin host and make all this automatic, and presumably that's how Overbridge works too.

I saw there was some work to turn Overwitch into a library in https://github.com/dagargo/overwitch/issues/25, so maybe this is already feasible. Unfortunately I don't have any experience with plugin development, but maybe if I get annoyed enough by my current workaround I might start learning this stuff :sweat_smile:

[dagargo]

The internal Overwitch library is supposed to work and its API, although obscure, is what it's used in overwitch-play and overwitch-record. overwitch and overwitch-cli use it also but they use the internal resampler too which is the complicated stuff.

To be honest, as I never cared much about the latency, I never got to implement anything related to it inside Overwitch and relied on the users and their DAWs configurations.

But it should be perfectly possible to tackle the latency as the JACK API allows to report it. See https://jackaudio.org/api/group__LatencyFunctions.html and https://jackaudio.org/api/group__LatencyFunctions.html#ga7a8f181fcec32945db7b8e06ee1ca94b.

Latency is already calculated as you can see in both the GUI and the CLI so we can just inform JACK about it. Doesn't look difficult.

If you're interested and available to do some testing, we can reopen the issue and give this a try. What do you think?

[toupeira]

Oh that sounds neat, I'd be happy to do some testing! I don't have experience with the JACK API either though, so I probably won't be able to help you with the implementation.

[dagargo]

Albeit there is another issue going on over master branch (#53), we can start testing this.

Code is in the latency-control branch. It implements automatic latency report to JACK so user shouldn't care about this at all. But I haven't tried this properly as my Digitakt doesn't send audio internally from input to output. (I've tried with a loopback cable but didn't notice much difference or latency.)

@toupeira, can you test this?

[dagargo]

Any update on this?

[toupeira]

@dagargo sorry I didn't get around to testing yet, but it's on my radar and I hope to find some time next week! :crossed_fingers:

[toupeira]

@dagargo ok tested this now! I don't see a real difference either, but maybe that's because Bitwig isn't doing anything with this latency information. I'll contact their support to see if they can shed some light on this.

For reference, my test setup is as follows:

• Bitwig with JACK 2 (not Pipewire), using 48kHz / 128 frames / 3 periods.
• Syntakt's line outputs are connected to my audio interface (Tascam Model 12), which is set as the main device in JACK.
• I'm playing a square wave sample from Bitwig, routed to the Analog FX inputs on the Syntakt (this goes through Overwitch, so I assume this adds latency as well)
• Bitwig records both the direct input through the audio interface, and the Overwitch main outputs.

Here's how that looks in Bitwig:

And here's how Overwitch looks:

master	latency-control

The latency numbers here don't stay stable and vary around +/- 1ms. I guess this is expected?

Some other notes:

• The delay for the DI vs. Overwitch recording is around 5-6ms, which roughly matches the sum of the latencies reported by Overwitch.
• As you can see the DI recording is delayed by about 5ms as well, this is due to my interface's roundtrip latency which I haven't yet fully sorted out. For this test I set the recording offset in Bitwig to zero.
• At first I had a different test setup with a pattern on the Syntakt with a kick on step 1, and triggered playback through the Bitwig transport (over MIDI). The results there were pretty much the same (i.e. no difference to the master branch), but because this also adds MIDI latency I figured I'd try another way too.

[dagargo]

Thank you so much for that thorough explanation.

I've been very busy lately so I still have to run the tests I wanted. Sorry. However, I'm considering assuming #53 as fixed, merging the branch latency-report, releasing version 1.1 soon and fix whatever we might find later in future releases. A Flatpak would be nice addition but the 1.1 release needs to happen before it.

Still figuring things out but the release will occur surely before the end of January.

A couple of notes.

The delay for the DI vs. Overwitch recording is around 5-6ms, which roughly matches the sum of the latencies reported by Overwitch.

Yes, that's the total delay. What I expected was for Bitwig to shift the recordings based on the reported latencies. I guess you were expecting that too.

Let's wait for the response from the Bitwig team.

The latency numbers here don't stay stable and vary around +/- 1ms. I guess this is expected?

They are expected to fluctuate. The latency is the amount of samples in the internal buffers and this varies with time. (The numbers are not showed continuously but in 2 s intervals.) The numbers in the square brackets are the ones reported to JACK and are the lowest theoretical value (MAX(period size / sampling rate, Overbridge latency)) and highest measured value, so the latter will be stable after some time.

(The underlying issue with the variations is that the Overwitch to JACK copy happens always in blocks of powers of 2 samples whereas the Syntakt to Overwitch copy is done in multiples of 7 samples as this is the size of an Overbridge block).

I'm playing a square wave sample from Bitwig, routed to the Analog FX inputs on the Syntakt (this goes through Overwitch, so I assume this adds latency as well)

In JACK, the reported latencies are meant to be added, meaning that the total latency will be the sum of the latencies along the signal path (JACK graph). Some plugins might not add a delay but others, as Overwitch, will surely do. So the total delay depends on the actual connections and every time the connection graph changes latencies need to be recalculated.

[toupeira]

I was curious how Ardour handles this, I tried it out in the past so I was somewhat familiar with its complex routing :) But there's no difference there either (again with the square wave through the Analog FX inputs):

At least nothing seems to break in the latency-control branch, so your plan to merge it sounds good to me!

Yes, that's the total delay. What I expected was for Bitwig to shift the recordings based on the reported latencies. I guess you were expecting that too.

Yes exactly, ideally the Overwitch recording would line up with the DI recording, and then I could set the global recording offset in Bitwig to shift all recordings forward until they end up at zero.

Let's wait for the response from the Bitwig team.

Will definitely keep you posted, although I don't expect that they have a lot of motivation to look deeply into this :wink: Especially since even Ardour doesn't seem to handle this either.

Thanks for the other technical details! Although I still don't really understand the latency variations, I guess those are only happening internally inside Overwitch? Otherwise I'd expect longer recordings to have glitches/dropouts when the latency changes, which doesn't seem to happen.

[toupeira]

Here's Bitwig's response:

our JACK implementation uses jack_port_get_total_latency to get the latency, but most likely there will not be any further development on the JACK side of things by us as we suggest using PipeWire instead of it these days.

Which I guess is fair enough :wink:

I'll keep using the Time Shift device as a workaround, and also wanted to give PipeWire another try anyway since the 1.0 release (it wasn't very stable for me in the past). If I find a more general solution I'll probably submit a PR to the README.

I'll go ahead and close this issue, thanks again for your help! :grinning:

[dagargo]

Branch latency-control merged manually into master.