You are not logged in.

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

HiddenSurface
Member
Registered: 2021-11-01
Posts: 2

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

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! smile


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)

Offline

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

michelesr
Member
Registered: 2016-02-04
Posts: 64

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

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)

Offline

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

HiddenSurface
Member
Registered: 2021-11-01
Posts: 2

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

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.

Offline

Board footer

Powered by FluxBB