Linux latency with pipewire?

Hi, I only use the Pipewire Sound Server and have banned Jack. (Bitwig DAW runs fine with Pipewire) However, I use openSuse tumbleweed (Liquorix kernel) and a Doug Audio USB DAC with 48k sample rate 256 or less samples. Korg D1 as master keyboard. I can't detect any delays when playing. (Subjective) Start in terminal pw-top (Manual with: man pw-top). The correct settings for the DAC can vary depending on the model and I have also noticed differences with the USB port (2 or 3). (Cheap DAC)

see also: https://wiki.archlinux.org/title/PipeWire

Hi, thanks for replying!  I don't have Jack installed either - pipewire-jack is pipewire pretending to be Jack for the benefit of client applications like pianoteq.

I just measured my sound card round trip time using audacity and a microphone, it's 29 ms - doesn't seem terrible.

After that, at @Lycomedes suggestion I set my sample rate to 48k and quantum to 256 (which I assume means a buffer capable of holding 256 samples?), ending up with this config (should I set min/max/force values too? couldn't figure out how to do that):

Unfortunately no obvious effect: still a noticeable delay of perhaps 100 ms.

Just in case this was all in my head, I thought to try with the headphones connected to the roland on one ear, and pianoteq's output on the other ear. Very clear delay.

Then I wrote a script to generate a sound that simulates that (two middle C notes played a short time apart).  From comparing that with the two-headphones test, I think the delay between the roland and pianoteq outputs reaching my ears is about 80 ms (plus or minus max 20 ms).

So with USB audio output contributing say 20 ms max (measured 29 ms round trip), that leaves roughly 60 ms to be accounted for in the pipeline involving USB midi input and pianoteq processing.  Does that seem too high?  Should I be able to reduce it?  Or should I just be less fussy?

If you want to try and quantify your latency somewhat, this is what I used to compare with the two-headphones test:

import numpy as np
import pyaudio

sample_rate = 44100
duration = 1  # in seconds
frequency_C = 261.63  # middle C in Hz
delay = 0.08  # 80 ms

t = np.linspace(0, duration, int(sample_rate * duration), False)
tone_C = 0.5 * np.sin(2 * np.pi * frequency_C * t)

delayed = tone_C.copy()
delayed[:int(sample_rate * delay)] = 0

# superimpose the two tones
mixed_tone = tone_C + delayed[:len(tone_C)]

# normalize to 16-bit range
mixed_tone = (mixed_tone * 32767).astype(np.int16)

# play
p = pyaudio.PyAudio()
stream = p.open(format=pyaudio.paInt16, channels=1, rate=sample_rate, output=True, output_device_index=7)
try:
    stream.write(mixed_tone.tobytes())
finally:
    stream.stop_stream()
    stream.close()
    p.terminate()

To run that you'd need `numpy` and `pyaudio` installed from PyPI - I won't go into how to install those since I wouldn't know where I'm starting from in the context of your system and background knowledge.  Also it seems one needs to figure out which output_device_index to use - for that I used this snippet and looked for a device named "pipewire" in the output:

for i in range(p.get_device_count()):
    print(i, p.get_device_info_by_index(i))

One thing that makes this harder: I can see that pianoteq retains its settings across restarts, and even if I wipe the directory where I extracted the demo and extract the demo again before restarting.

I wonder where it stores its settings, so I can wipe them to help me see exactly what makes the difference?  But maybe that's for another thread.

Perhaps from bitter experience from software as a day job, I never fully trust ways to "reset" software that are controlled by the software itself!  I'd rather just wipe it completely and try again.

Experimenting some more (reboots, removing PT config file, changing PT settings):

I think most of the difference is just from the buffer size.  I believe when I reported still hearing noticeable latency at 48k sample rate and 256 buffer in pianoteq didn't make much difference, I was *expecting* to still hear the delay, and I did for real, but it was significantly reduced but just about still audible.  Really it's not very noticeable at all at the level I'm now seeing even at 256 and perhaps 128 is even better.

So basically @Lycomedes had it exactly right (also they suggested 128 buffer size and I'd not paid attention and picked 256).

Only thing I'm still a bit surprised by is that having "measured" (in the somewhat sloppy way available to me) around 80 ms total latency, I was surprised that the difference between 10 ms and 5 ms (512 and 256 buffer size at 48k) made an audible difference.  But it seems to, I can't explain why.

I suspect you've solved your problem by now, but I wanted to share a small quirk I discovered about pipewire. Pipewire has this behavior where it will use the highest quality settings asked for by any program running on your computer for all running programs in your computer. What I mean by that is that by starting a second program that asks for a lower quantum value (e.g. pavucontrol), all other running programs now suddenly also use the lower quantum value which can result in sudden "magic" solution for problems "without changing any settings".