Pipewire for Pro Audio:Low displayed latency but high audible latency

HiddenSurface · 2021-11-01 15:59:34

Hi,

I had numerous problems getting to work Pulseaudio together with Jack, so I switched to Pipewire, which overall seems to work much better with my external Firewire Audiointerface (RME Fireface 800).

However, I still have pretty high audible latency when using Reaper or Bitwig Studio, regardless if I use pipewire-pulse or pipewire-jack.

If I configure Reaper to use a blocksize of 16 at 48kHz for example (with PulseAudio API), the displayed (client) latency is very low (<2ms), but when playing my Midi Keyboard, I can still hear a latency of at least 80-100ms:

https://cloud.yunie.de/apps/files_shari … calingup=0

The QUANT displayed for the Reaper client in pw-top is 5040, which kind of highlights that there is a problem there, but I can't find a way to change that number through configuration.

The rtkit-Module is enabled in /etc/pipewire/pipewire.conf and /etc/pipewire/pipewire-pulse.conf.

I have configured the quantum to be pretty low in pipewire.conf:

    ## Properties for the DSP configuration.
    #default.clock.rate          = 48000
    #default.clock.allowed-rates = [ 48000 ]
    default.clock.quantum       = 128
    default.clock.min-quantum   = 32
    default.clock.max-quantum   = 1024 # 512 
    #default.video.width         = 640
    #default.video.height        = 480
    #default.video.rate.num      = 25
    #default.video.rate.denom    = 1
    #
    # These overrides are only applied when running in a vm.
    vm.overrides = {
        default.clock.min-quantum = 1024
    }

According to the configuration in pipewire-pulse.conf, the buffer size should also be much lower:

    { name = libpipewire-module-protocol-pulse
        args = {
            # the addresses this server listens on
            server.address = [
                "unix:native"
                #"unix:/tmp/something"              # absolute paths may be used
                #"tcp:4713"                         # IPv4 and IPv6 on all addresses
                #"tcp:[::]:9999"                    # IPv6 on all addresses
                #"tcp:127.0.0.1:8888"               # IPv4 on a single address
            ]
            pulse.min.req          = 256/48000     # 5ms
            pulse.default.req      = 960/48000     # 20 milliseconds
            #pulse.min.frag         = 256/48000     # 5ms
            #pulse.default.frag     = 96000/48000   # 2 seconds
            #pulse.default.tlength  = 96000/48000   # 2 seconds
            pulse.min.quantum      = 256/48000     # 5ms
            pulse.default.format   = F32
            #pulse.default.position = [ FL FR ]
            # These overrides are only applied when running in a vm.
            vm.overrides = {
                pulse.min.quantum = 1024/48000      # 22ms
            }
        }
    }

I suspect that realtime scheduling may not be working correctly. How would I verify that?

journalctl -xe | grep pipewire does not output anything suspicious:

Nov 01 16:44:28 arch pipewire-pulse[708]: mod.protocol-pulse: client 0x56239f3fd770 [libcanberra]: ERROR command:18 (PLAY_SAMPLE) tag:196 error:25 (Input/output error)
Nov 01 16:45:08 arch systemd[697]: pipewire-media-session.service: Consumed 1.100s CPU time.
Nov 01 16:45:08 arch systemd[697]: pipewire.service: Consumed 1min 42.073s CPU time.
Nov 01 16:45:11 arch dbus-daemon[440]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.223' (uid=1000 pid=21605 comm="/usr/bin/pipewire-media-session ")
Nov 01 16:45:11 arch pipewire-media-session[21605]: spa.bluez5: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit

If I use the JACK interface by starting reaper with for example PIPEWIRE_LATENCY="32/48000" pw-jack reaper, it actually seems to be using a blocksize of 32 Samples, and the client latency is very low (0.6ms). The QUANT value in pw-top is supposedly 32 then, but the audible latency is still in the 80-100ms range, so it must have something to do with the Pipewire configuration itself.

Edit: If I use a HDMI-Audio-Output instead of the Firewire Interface, I get much better latency, btw.

I am not using a realtime kernel, but as I understand it, that is not necessary for achieving low latencies.

Do you have any idea what I could try?

Thank you very much!

Edit2: I think it has to do with the following problem: https://gitlab.freedesktop.org/pipewire … te_1106721

Mod Edit - Replaced oversized image with link.
CoC - Pasting pictures and code

Last edited by Slithery (2021-11-22 01:01:28)

michelesr · 2021-11-10 14:51:22

I had very high latency on my Focusrite Scarlett 2i2 3rd gen (USB), and managed to get that right by setting the api.alsa.period-size parameter to a very low value, at ~/.config/pipewire/media-session.d/alsa-monitor.conf (you can copy the example from /usr/share/pipewire/media-session.d/alsa-monitor.conf if you don't have that config file)

...
{
matches = [
{
node.name = "alsa_input.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.analog-stereo"
}
{
node.name = "alsa_output.usb-Focusrite_Scarlett_2i2_USB_Y8AUM280954FBA-00.analog-stereo"
}
]
actions = {
update-props = {
api.alsa.period-size = 2
# api.alsa.disable-batch = false
# audio.rate = 48000
# audio.format = "S32_LE"
}
}
}
...

You can test your roundtrip latency using jack_iodelay, I get around 6.5ms with a buffer size of 64, which is similar to what I get with JACK.

Not sure it will help in your case but is worthy a try if you didn't already.

Last edited by michelesr (2021-11-10 14:53:20)

HiddenSurface · 2021-11-22 00:31:25

Hi michelesr,

thanks for your answer!

Yes, I tried reducing the period size after finding the relevant discussion of the pipewire developers, however, to no avail. This problem seems to be specific to Firewire Cards.

Arch Linux

#1 2021-11-01 15:59:34

Pipewire for Pro Audio:Low displayed latency but high audible latency

#2 2021-11-10 14:51:22

Re: Pipewire for Pro Audio:Low displayed latency but high audible latency

#3 2021-11-22 00:31:25

Re: Pipewire for Pro Audio:Low displayed latency but high audible latency

Board footer