Timing issues with PipeWire

[dagargo]

The issue seems to appear at random but it also happens when making JACK connections to Overwitch or any other client or hardware.

The clock drifts, and so the ratios, and the buffers get filled up with more data increasing the latency. This is more noticeable in the JACK to Overbridge side.

This is an example of Overwitch running.

$ overwitch -vv
[...]
Digitakt@001,010: o2p latency:  0,8 ms, max.  2,0 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 0,999885, avg. 0,999886
Digitakt@001,010: o2p latency:  0,9 ms, max.  2,0 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 0,999890, avg. 0,999888
Digitakt@001,010: o2p latency:  0,9 ms, max.  2,0 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 0,999887, avg. 0,999889

Just when making a connection this happens (ratio drift).

Digitakt@001,010: o2p latency:  1,0 ms, max.  2,0 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000689, avg. 1,000174
Digitakt@001,010: o2p latency:  0,9 ms, max.  2,6 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,001095, avg. 1,000895
Digitakt@001,010: o2p latency:  3,8 ms, max.  3,9 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,001637, avg. 1,001503
Digitakt@001,010: o2p latency:  8,0 ms, max.  8,1 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000923, avg. 1,001297
Digitakt@001,010: o2p latency:  9,5 ms, max.  9,9 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000460, avg. 1,000660
Digitakt@001,010: o2p latency: 10,4 ms, max. 10,6 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000241, avg. 1,000340
Digitakt@001,010: o2p latency:  9,7 ms, max. 10,8 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000126, avg. 1,000175
Digitakt@001,010: o2p latency: 10,1 ms, max. 11,1 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 1,000014, avg. 1,000075
Digitakt@001,010: o2p latency: 10,3 ms, max. 11,2 ms; p2o latency: -1,0 ms, max. -1,0 ms, o2p ratio: 0,999912, avg. 0,999958

After a few connections, the delays are unacceptable.

The issue appears when making connections from Ardour or qpwgraph. It doesn't make any difference if Ardour is up or down.

Sometimes, the ratios are not right from the start, meaning that I know that the o2p ratio in my device is around 0,999885 and being greater than 1.0 is a symptom that the clock will drift later.

$ pipewire --version
pipewire
Compiled with libpipewire 0.3.76
Linked with libpipewire 0.3.76

[dagargo]

With PipeWire 0.3.77, the issue don't arise when making connections but still appear at random.

But it's much more stable now.

[dagargo]

After more testing, I can confirm that with version 0.3.77 making connections still causes timing issues.

I've tried setting the api.alsa.disable-tsched property as explained in this PipeWire issue without success.

[dagargo]

Seems that everything is working great again with version 0.3.80.

Some issues have been solved in the recent releases but I've just discovered that I wasn't calling rtirq properly, so the RT priorities were not set up as needed to ensure low latency. So this issue was probably my fault.

Leaving this open for now as I want to run more tests.

[dagargo]

Looks like the issue is still there and the changes I saw were just caused by having Ardour running before launching Overwitch.

Perhaps the issue is related to the way the JACK client is created.

[dagargo]

I've asked to the PipeWire team about this here.

[dagargo]

PipeWire support improved in b869eed544908284bfd0428361a41bbe50b6e05a.

It's recommended to use the Pro audio profile and pass the environment variable PIPEWIRE_PROPS indicating the hardware to be assigned to and scheduled with.

$ PIPEWIRE_PROPS='node.link-group=pro-audio-0 overwitch-cli

The GUI may use this or use the settings to internally set this variable.

See the README.md section for more information.