Problem when using Bitwig on Jack

[Llamatron2112]

There is an issue when using Overwitch with Bitwig and Jackd : when opening the tracks input or output menu, a xrun happens, and the Overwitch engine reinitalizes.

My system is Arch, with Overwitch from the AUR, and I tried with Analog 4 mk2 and Digitakt 2

I tried to fiddle with the number of buffers, jack buffer size, number of periods, nothing fixed it. It works better in that regard when using pipewire-jack, but there is other issues (I will probably report it too)

Here is the log when that happens

DEBUG:main-service.c:495:startup: Setting PIPEWIRE_PROPS to '{ node.group = "pro-audio-0" }'...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:308:ow_get_device_desc_file: Searching device in /home/llamatron/.config/overwitch/devices.json
DEBUG:overwitch.c:161:ow_get_device_desc_reader: Device with PID 2887 found
DEBUG:overwitch.c:90:ow_get_device_list: Found Analog Four MKII (bus 001, address 009, ID 1935:0b47)
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:overwitch.c:82:ow_get_device_list: Non Elektron USB device found. Skipping...
DEBUG:engine.c:547:ow_engine_init: USB transfer timeout: 20
DEBUG:engine.c:429:ow_engine_init_mem: Blocks per transfer: 8
DEBUG:engine.c:443:ow_engine_init_mem: o2h: USB in frame size: 32 B
DEBUG:engine.c:444:ow_engine_init_mem: h2o: USB out frame size: 24 B
DEBUG:engine.c:472:ow_engine_init_mem: o2h: USB in block size: 256 B
DEBUG:engine.c:474:ow_engine_init_mem: h2o: USB out block size: 200 B
DEBUG:engine.c:482:ow_engine_init_mem: o2h: audio transfer size: 1792 B
DEBUG:engine.c:484:ow_engine_init_mem: h2o: audio transfer size: 1344 B
DEBUG:engine.c:1082:ow_engine_load_overbridge_name: USB control in data (32 B): Analog Four
DEBUG:engine.c:1102:ow_engine_load_overbridge_name: USB control in data (16 B): 0183        1.52
DEBUG:dll.c:153:ow_dll_host_init: Initializing host side of DLL...
DEBUG:main-service.c:180:start_single: Starting pooled jclient 0...
DEBUG:jclient.c:568:jclient_start: Starting thread...
DEBUG:jclient.c:175:jclient_set_sample_rate_cb: JACK sample rate: 48000
DEBUG:jclient.c:446:jclient_run: Using RT priority 85...
DEBUG:jclient.c:448:jclient_run: Registering ports...
DEBUG:jclient.c:453:jclient_run: Registering output port Main L...
DEBUG:jclient.c:453:jclient_run: Registering output port Main R...
DEBUG:jclient.c:453:jclient_run: Registering output port Synth Track 1...
DEBUG:jclient.c:453:jclient_run: Registering output port Synth Track 2...
DEBUG:jclient.c:453:jclient_run: Registering output port Synth Track 3...
DEBUG:jclient.c:453:jclient_run: Registering output port Synth Track 4...
DEBUG:jclient.c:453:jclient_run: Registering output port Input L...
DEBUG:jclient.c:453:jclient_run: Registering output port Input R...
DEBUG:jclient.c:472:jclient_run: Registering input port Main L Input...
DEBUG:jclient.c:472:jclient_run: Registering input port Main R Input...
DEBUG:jclient.c:472:jclient_run: Registering input port Synth Track 1 Input...
DEBUG:jclient.c:472:jclient_run: Registering input port Synth Track 2 Input...
DEBUG:jclient.c:472:jclient_run: Registering input port Synth Track 3 Input...
DEBUG:jclient.c:472:jclient_run: Registering input port Synth Track 4 Input...
DEBUG:resampler.c:588:ow_resampler_init_samplerate: Setting resampler sample rate to 48000
DEBUG:resampler.c:579:ow_resampler_init_buffer_size: Setting resampler buffer size to 128
DEBUG:resampler.c:175:ow_resampler_reset_buffers: Resetting buffers...
DEBUG:resampler.c:157:ow_resampler_clear_buffers: Clearing buffers...
DEBUG:dll.c:164:ow_dll_host_reset: Resetting the DLL...
DEBUG:engine.c:941:ow_engine_start: Starting thread...
DEBUG:dll.c:53:ow_dll_overbridge_init: Initializing Overbridge side of DLL (48000.0 Hz, 56 frames)...
DEBUG:jclient.c:518:jclient_run: Activating...
DEBUG:jclient.c:166:jclient_set_buffer_size_cb: JACK buffer size: 128
DEBUG:engine.c:1223:ow_hotplug_loop: Registering USB hotplug callback...
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:resampler.c:415:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Setting Overbridge side to steady (notifying readiness)...
DEBUG:engine.c:773:run_audio: Notification of readiness received from resampler
DEBUG:engine.c:795:run_audio: Booting or clearing engine...
DEBUG:dll.c:77:ow_dll_overbridge_update: Booting Overbridge side of DLL...
DEBUG:jclient.c:527:jclient_run: Activated
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 0, 0 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 0, 0 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 0, 0 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 0, 0 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:dll.c:124:ow_dll_host_update_error: Booting host side of DLL...
DEBUG:resampler.c:444:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Booting resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:resampler.c:467:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Tuning resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000120
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000088
DEBUG:resampler.c:486:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Running resampler...
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:resampler.c:307:resampler_o2h_reader: o2h: Emptying buffer (4096 B) and running...
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
DEBUG:resampler.c:290:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 1792)
Analog Four MKII @ 001,009 (Analog Four): o2h latency:  2.8 [ 2.7,  4.6] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000080
Analog Four MKII @ 001,009 (Analog Four): o2h latency:  3.8 [ 2.7,  4.8] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000023
Analog Four MKII @ 001,009 (Analog Four): o2h latency:  3.4 [ 2.7,  4.8] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 0.999991
Analog Four MKII @ 001,009 (Analog Four): o2h latency:  3.0 [ 2.7,  4.8] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 0.999979
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
ERROR:jclient.c:59:jclient_thread_xrun_cb: JACK xrun
DEBUG:resampler.c:231:ow_resampler_reset: Resetting resampler...
DEBUG:dll.c:153:ow_dll_host_init: Initializing host side of DLL...
DEBUG:dll.c:164:ow_dll_host_reset: Resetting the DLL...
DEBUG:resampler.c:157:ow_resampler_clear_buffers: Clearing buffers...
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:engine.c:845:run_audio: Clearing buffers...
DEBUG:engine.c:795:run_audio: Booting or clearing engine...
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 229 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:dll.c:77:ow_dll_overbridge_update: Booting Overbridge side of DLL...
DEBUG:dll.c:124:ow_dll_host_update_error: Booting host side of DLL...
DEBUG:resampler.c:444:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Booting resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
ERROR:jclient.c:59:jclient_thread_xrun_cb: JACK xrun
DEBUG:resampler.c:231:ow_resampler_reset: Resetting resampler...
DEBUG:dll.c:153:ow_dll_host_init: Initializing host side of DLL...
DEBUG:dll.c:164:ow_dll_host_reset: Resetting the DLL...
DEBUG:resampler.c:157:ow_resampler_clear_buffers: Clearing buffers...
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:dll.c:77:ow_dll_overbridge_update: Booting Overbridge side of DLL...
DEBUG:engine.c:845:run_audio: Clearing buffers...
DEBUG:engine.c:795:run_audio: Booting or clearing engine...
DEBUG:dll.c:124:ow_dll_host_update_error: Booting host side of DLL...
DEBUG:resampler.c:444:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Booting resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
ERROR:jclient.c:59:jclient_thread_xrun_cb: JACK xrun
DEBUG:resampler.c:231:ow_resampler_reset: Resetting resampler...
DEBUG:dll.c:153:ow_dll_host_init: Initializing host side of DLL...
DEBUG:dll.c:164:ow_dll_host_reset: Resetting the DLL...
DEBUG:resampler.c:157:ow_resampler_clear_buffers: Clearing buffers...
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:dll.c:77:ow_dll_overbridge_update: Booting Overbridge side of DLL...
DEBUG:engine.c:845:run_audio: Clearing buffers...
DEBUG:engine.c:795:run_audio: Booting or clearing engine...
DEBUG:dll.c:124:ow_dll_host_update_error: Booting host side of DLL...
DEBUG:resampler.c:444:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Booting resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 0.999976
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 0.999702
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
ERROR:jclient.c:59:jclient_thread_xrun_cb: JACK xrun
DEBUG:resampler.c:231:ow_resampler_reset: Resetting resampler...
DEBUG:dll.c:153:ow_dll_host_init: Initializing host side of DLL...
DEBUG:dll.c:164:ow_dll_host_reset: Resetting the DLL...
DEBUG:resampler.c:157:ow_resampler_clear_buffers: Clearing buffers...
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:92:jclient_set_latency_cb: h2o latency: [ 128, 128 ]
DEBUG:jclient.c:74:jclient_set_latency_cb: JACK latency request
DEBUG:jclient.c:78:jclient_set_latency_cb: o2h latency: [ 128, 128 ]
DEBUG:jclient.c:150:jclient_jack_graph_order_cb: JACK calling graph order...
DEBUG:dll.c:77:ow_dll_overbridge_update: Booting Overbridge side of DLL...
DEBUG:engine.c:845:run_audio: Clearing buffers...
DEBUG:engine.c:795:run_audio: Booting or clearing engine...
DEBUG:dll.c:124:ow_dll_host_update_error: Booting host side of DLL...
DEBUG:resampler.c:444:ow_resampler_compute_ratios: Analog Four MKII @ 001,009 (Analog Four): Booting resampler...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
DEBUG:jclient.c:115:jclient_port_connect_cb: JACK port connect request
ERROR:resampler.c:329:ow_resampler_read_audio: o2h: Unexpected frames with ratio -0.193223 (output 0, expected 128)
DEBUG:jclient.c:293:jclient_stop: Stopping client...
DEBUG:resampler.c:635:ow_resampler_stop: Stopping resampler...
DEBUG:engine.c:1066:ow_engine_stop: Stopping engine...
DEBUG:engine.c:857:run_audio: Processing remaining events...
Analog Four MKII @ 001,009 (Analog Four): o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: -0.193223
DEBUG:jclient.c:532:jclient_run: Exiting...

[dagargo]

This is a known issue but let me explain myself.

An xrun happens when an audio cycle couldn't be completed in the time assigned to it, which can be caused by any of the clients in the audio graph. For instance, Bitwig might take longer than expected to compute its output under some circumstances causing all the remaining clients to fail to deliver. But, due to the way audio goes through the JACK graph, it is unknown to the clients which other client failed. Moreover, one client might 'fail' to fulfil the time requirements because one of the previously computed clients took too long. All in all, every application might want to proceed differently to overcome xruns that are not even their own fault and, in the case of Overwitch dealing with this is particularly tricky because of the internal resampler.

Also, keep in mind that PipeWire is a quite new component. It's pretty stable right now and works wonderfully well but there might be some issues.

Anyway, let's check a few things to try to improve this issue.

• If possible, and based on my own experience, try not to patch new things while you are recording.
• Try to disable the dummy cores, either intel intel hyperthread or AMD SMT.
• As you have PIPEWIRE_PROPS set, let's check that the value is right. Can you post the output of pw-top? We should see that your devices are run in the same node as the hardware node.
• A JACK buffer size of 256 or 512 should fix your issue but values higher than 128 have a noticeable delay.

Regardless of these suggestions to mitigate the issue, since I've faced this in the past, I want to give this a new try now that PipeWire is stable (I tried this about a year ago). In particular, if the resampler is in the running state, the idea is not to reset the resampler and to skip a whole iteration instead ratio calculation included. This will mean skipping any audio processing, which will surely create a dropout in the audio but will keep the latency at reasonable values.

I'll give it a try during December and let you know.

By the way, this has been moved to version 2.2 and it's the only thing there.

[Llamatron2112]

Thanks for your answer, and also for your work on Overwitch and Elektroid !

I am aiming at using 128 samples buffers as it is the best my sound card can do, but I tried with bigger buffers up to 1024 samples, and also adding more buffers, without improvement. There really is something Overwitch doesn't like in those requests, when Bitwigs create connections to all the channels of a device, probably to display their vu-meter in the menu, when running with a Jack server. I thought it could be the amount of requests as initially I used it with my Digitakt 2 which has more than 16 stereo channels, with some effects. But it happens with my Analog 4 mk2 with 4 mono channels and some effects. Only Bitwig has this problem, Ardour works fine, and sometime crashes Overwitch's engine, but it's quite rare.

I would have prefered to use Jack, as Pipewire had the same problem, and also others, like Overwitch's latency sometime rising very high, and the presence in the graph of all devices known to Pipewire that are creating unecessary clutter, especially as some devices appear more than once, and pretty often crash Bitwig's or Overwitch's engines if accidentally moused over in the menu.

After spending some time optimizing a bit my computer for audio, mostly by isolating cores for critical audio components, Pipewire ends being pretty much crash free, even on a non realtime kernel, and after some fiddling it has been possible to supress the crashes due to mousing over the wrong devices, so I can use Bitwig pretty much normally now. I hadn't tried matching the node.group Pipewire parameter to the same as my sound card, but it looks like it helped. Maybe I could set something similar for Bitwig using rules in Pipewire, see if it helps too.

It would be nice if you could find a way to resync the resampler without going through all the initialization, if there is no way to get rid of those xruns with Jack, as it is pretty frustrating to be without sound for that amount of time. I wouldn't mind just having crackles, like pretty much all Jack based software do when a xrun happens. Since I managed to tame Pipewire a bit, at least I can spend time doing music now, so it is less of a critical matter for me.

Ha and in case it could be usefull to you or other people, I made a .spec file to package Overwitch in RPM format for Fedora, and have put it on COPR in a project with an unrelated name. I hope that's OK for you, let me know if you have any suggestion.

[dagargo]

Thanks for your answer, and also for your work on Overwitch and Elektroid !

Glad you find these useful! 🙂

I am aiming at using 128 samples buffers as it is the best my sound card can do.

This is a very safe assumption. Everything should work fine with 128 samples and Overwitch latency should be around 5 s, which is not bad.

Only Bitwig has this problem, Ardour works fine, and sometime crashes Overwitch's engine, but it's quite rare.

That's what I was trying to explain. If an application does something wrong latency-wise causing an xrun, it is gonna affect all the other running applications one way or another. The problem with Overwitch is that it is very sensitive to these scenarios and, by design, it restarts itself on an xrun. This is what I want to change in version 2.2.

It would be nice if you could find a way to resync the resampler without going through all the initialization, if there is no way to get rid of those xruns with Jack, as it is pretty frustrating to be without sound for that amount of time. I wouldn't mind just having crackles, like pretty much all Jack based software do when a xrun happens.

Exactly this. I fully agree but never found a way to improve the situation. In fact, yesterday I spent the whole evening doing tests and trying this and that and achieved nothing. But today I've just came up with an idea that seems to just work.
It workarounds the xrun issue by just going back to the tuning state, which is achieved by doing 2 things.

1. Clear the resampler buffers, so that latency is under control.
2. Set the resampler status to tune, so that it will adjust faster to the wobbling time measurements caused by the audio server as a response to the xrun.

I've uploaded the code to the feat-add-xrun-recovery branch. Would you mind checking it out and reporting back?

Ha and in case it could be usefull to you or other people, I made a .spec file to package Overwitch in RPM format for Fedora, and have put it on COPR in a project with an unrelated name. I hope that's OK for you, let me know if you have any suggestion.

Why under an unrelated name? Wouldn't it make it more difficult to find it there? Or have I misunderstood something?Besides, @jwakely, added it to COPR at some point. Check it out at https://copr.fedorainfracloud.org/coprs/jwakely/overwitch/. Is yours the same thing?

[Llamatron2112]

So I compiled and ran the code from that branch. First times I tried with the GUI and when opening the menu of death it first froze all the GUIs involved (qjackctl, Bitwig and Overwitch), second time it froze the whole system, and finally when I launched it in the terminal with -vv to try to capture some logs, both times initialized the engine, then filled the terminal buffer with

DEBUG:resampler.c:296:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 B < 9408 B). No fix possible.

As you have PIPEWIRE_PROPS set, let's check that the value is right. Can you post the output of pw-top? We should see that your devices are run in the same node as the hardware node.

Regarding the pipewire props in the config file, after a bit of experimenting it doesn't seem to do anything, at least with wpctl inspect I don't even see the property on the node, so I guess it has no effect.

Why under an unrelated name? Wouldn't it make it more difficult to find it there? Or have I misunderstood something?Besides, @jwakely, added it to COPR at some point. Check it out at https://copr.fedorainfracloud.org/coprs/jwakely/overwitch/. Is yours the same thing?

The one from jwakely is very old, mine is the very latest 2.1.1. I know some devs don't like to see their software being redistributed out of their control, but if you're fine with it I will make a proper project for that package.

Is the code on the main branch on Github usually tested a bit so it doesn't break completely ? Maybe it could be possible to have a git package that autoupdates when the code has been changed, along with the latest release.

[jwakely]

Besides, @jwakely, added it to COPR at some point. Check it out at https://copr.fedorainfracloud.org/coprs/jwakely/overwitch/. Is yours the same thing?

I haven't updated that in a very long time though.

[dagargo]

when opening the menu of death it first froze all the GUIs involved (qjackctl, Bitwig and Overwitch)

No idea of what's going on but I'd blame this on Bitwig if it didn't happen with Ardour. Are you running the latest version? I know that a newer one was released not long ago.

Also, I changed something in the code and you shouldn't see that error with -vv but with -vvv now. So it's weird if you're seeing that.

Regarding the PIPEWIRE_PROPS, the particular property node.group makes the process to follow that node and by using the value of the hardware node the process follows the hardware. This is important when creating connections because there might be noticeable delays when creating them as they don't run together. The best way to know if the property is right is by running pw-top and check if the process hangs from the node.

I know some devs don't like to see their software being redistributed out of their control, but if you're fine with it I will make a proper project for that package.

Although I might understand that it looks like a lose of control, that's not my case. This is free software and it's there for everyone to use it the way they want whilst sticking with the license. In particular, dealing with distribution packages is a completely different thing and unknown to me that would require lot of time. So, definitely, I'm very happy to see that someone considers this project deserves to be packaged.
So, thanks for asking anyway and thanks for packaging it. 🙂

[Llamatron2112]

No idea of what's going on but I'd blame this on Bitwig if it didn't happen with Ardour. Are you running the latest version? I know that a newer one was released not long ago.

Yes that is what I am begining to think too, well it would also be better if Overwitch could recover from a xrun without going through all the initialization process, but I understand it is not so easy. I am running current latest stable 5.x Bitwig version, but they are doing release candidates for version 6 since the end of summer.

Regarding the PIPEWIRE_PROPS, the particular property node.group makes the process to follow that node and by using the value of the hardware node the process follows the hardware. This is important when creating connections because there might be noticeable delays when creating them as they don't run together. The best way to know if the property is right is by running pw-top and check if the process hangs from the node.

Thanks for the infos ! Pipewire has lots of stuff to grasp and I started really looking into it recently. How is the info displayed in pw-top ? Is it all the entries that are indented after a node that are in the same group ? That would be a bit weird as I see my internal sound card in the indented list below my USB one. Or maybe it is why doing a mouseoverr on it in Bitwig breaks things.

Although I might understand that it looks like a lose of control, that's not my case. This is free software and it's there for everyone to use it the way they want whilst sticking with the license. In particular, dealing with distribution packages is a completely different thing and unknown to me that would require lot of time. So, definitely, I'm very happy to see that someone considers this project deserves to be packaged. So, thanks for asking anyway and thanks for packaging it. 🙂

I made a project page so people can find it https://copr.fedorainfracloud.org/coprs/llamatron/overwitch/ didn't really know how to fill all the text fields so I went minimal.

[dagargo]

Just for reference, this is the output of pw-top in my system.

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME                                                              
I   30      0      0   0,0us   0,0us  ???   ???     0                  Dummy-Driver
S   31      0      0    ---     ---   ---   ---     0                  Freewheel-Driver
R   57    128  48000 229,0us   0,5us  0,09  0,00   10   S32LE 14 48000 alsa_input.usb-Soundcraft_Soundcraft_Signature_12_MTK-00.pro-input
R   44      0      0   5,5us   3,9us  0,00  0,00   84                   + Midi-Bridge
R   53      0      0   5,7us   0,9us  0,00  0,00    0                   + bluez_midi.server
R   56      0      0   4,0us   4,9us  0,00  0,00  144   S32LE 12 48000  + alsa_output.usb-Soundcraft_Soundcraft_Signature_12_MTK-00.pro-o
R  100      0      0   7,1us  73,1us  0,00  0,03    0                   + Digitakt
R  116      0      0   5,3us  25,7us  0,00  0,01    0                   + sfxd
R  124      0      0   5,2us  88,2us  0,00  0,03   23                   + ardour
R  247    256  48000   9,2us   5,3us  0,00  0,00    0    F32LE 2 48000  + Elektroid
S  248      0      0    ---     ---   ---   ---     0                   + Elektroid

In PipeWire, once a client is connected to the hardware node, it depends on the hardware node (as in computed together with) and it's shown as hanging from it. But this can be forced with PIPEWIRE_PROPS='{ node.group = "pro-audio-0" }'.

As it might take some time for a client to be moved under the hardware node when creating a connection, this might lead to huge increases of the audio buffers. This is the reason for the need of PIPEWIRE_PROPS.

[dagargo]

I've added a fix to avoid a full resampler reset in 1e7acbf. It works by doing the same as the tune state but with the addition of processing audio. There are some artifacts now but the audio stream is not cut for 7 s.

Besides, I've added a fix for handling negative ratios in ea90ec1. This scenario was happening more often than expected so it needed to be addressed. I'm still trying to improve this fix as it leads to huge increases in latency but it's a starting point.

By the way, I've seen a couple of full system crashes while testing all this.

Let me know if this improves your scenario.

By the way, regarding your question about autoupdating your package and Overwitch main branch stability, I can say that it's pretty stable now and I'm not planning on adding new functionalities but bugfixes only although I might perhaps remove the internal library because it makes it more difficult to package it.

I try to test everything but I'm the only one doing it on my system so it can't be said it's even tested.

Edit: And I've added 2cecfbb to retune when a negative ratio is detected to keep the latency under control.

[Llamatron2112]

This improves my scenarion with jackd a lot ! I will need to make longer testing as I didn't get any system crash yet, but so far I can tell that it even doesn't always produce artifacts after a xrun, and it looks like the other fixes for the negative ratios do good things to the latency.

EDIT: Ha actually the reported latency in the GUI doesn't seem to be right, when checking sound from bitwig there is a big latency while the GUI displays around 4ms

[dagargo]

EDIT: Ha actually the reported latency in the GUI doesn't seem to be right, when checking sound from bitwig there is a big latency while the GUI displays around 4ms

Is it possible that the latency is coming from somewhere else? In my tests, sometimes, when an xrun happened, other applications were adding latency and distortion that was unrelated to Overwitch but that was ultimately transmitted to the speakers via the audio path. Could you check if the actual audio coming out from Overwitch suffers this latency?

[Llamatron2112]

I have tried with 9 tracks from Overwitch, and Bitwig's metronome, and by ear I can tell that sometime the latency displayed by the GUI isn't right. Actually it usually resyncs after a xrun, but it seems to me there is a slight drift along time when there is none.

EDIT: Ha I had some drift after a lot of xruns too, but restarting playback seems to put everything back in place for a good moment

[dagargo]

But, can you try monitoring the direct output of Overwitch by connecting an output to any of your hardware inputs bypassing everything else?

I'm not saying there might not be bugs but the latency measurements are exactly the size of the audio buffers so I find pretty strange that Overwitch is adding a latency on its own other than the reported one.

However, I think I've perceived a delay between the actual adjustments and the moment these are reported in the GUI. I'll investigate this further.