Pipewire resource hog in version 1.4.1 - workaround

I run into 100% core use by usr/bin/pipewire. When looking at child and parent processes, clients, there was nothing abnormal. Then sudo strace -p 2402 -s 128 (where 2402 was the PID of pipewire) showed flooding with epoll_wait(5, [{events=EPOLLIN, data=0x7f416fbb10a8}], 32, -1) = 1

This then led to https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4507 and the solution - to disable MIDI (as I am not using any devices or software needing its use on my system). Solution:

# ~/.config/wireplumber/wireplumber.conf.d/nomidi.conf
wireplumber.profiles = {
    main = {
        monitor.alsa-midi = disabled
    }
}

i.e. create the file nomidi.conf in the specified location, put in the midi disabling code and restart wireplumber and pipewire:

systemctl --user restart wireplumber pipewire

Computer fans immediately go down and system is nice and quiet. Probably in the not so far future the bug will be fixed and I will need to remember to remove the file. Possibly the problem with my computer was exactly because there was no use of MIDI and the driver kept polling something that wasn’t there.

1 Like

alsa: seq: double-check midi client version (!2313) · Merge requests · PipeWire / pipewire · GitLab

Check midi client version after setting it, to see if it was really successfully set. Old kernels without UMP don’t know about the midi version fields, so snd_seq_set_client_midi_version() appears to fail silently there.

Closes #4621 (closed)

MIDI 2.0 on Linux — The Linux Kernel documentation