Pipewire Audio Driver

[rtbo]

Resolves (on linux): #18701

This is a new audio driver for Linux, that uses the Pipewire API, (and therefore will only be used when Pipewire is installed and running).
For system that do not have pipewire, it will fallback to ALSA automatically.

Pipewire performs a setup negotiation to match what is requested by the app and what is setup on the system.
So the buffer size is more a request for a certain latency rather than something imperative.
I've added support for "System default" buffer size where we don't request anything specific to pipewire.

In general, pipewire will handle gracefully all sorts of corner cases.
My observations are for a low latency playback, free of any glitch, in all situations.

Pipewire also provides the devices available, so the user can choose any playback device available, including bluetooth.
I didn't test yet with USB external device.

Relates to #23439

• I signed the CLA
• The title of the PR describes the problem it addresses
• Each commit's message describes its purpose and effects, and references the issue it resolves
• If changes are extensive, there is a sequence of easily reviewable commits
• The code in the PR follows the coding rules
• There are no unnecessary changes
• The code compiles and runs on my machine, preferably after each commit individually
• I created a unit test or vtest to verify the changes I made (if applicable)

[RomanPudashkin]

Great job, thank you so much! I asked @DmitryArefiev to test it. @MarcSabatella could you also test it? Thanks!

[DmitryArefiev]

@rtbo Tried on my LinuxUbuntu 22.04. The build doesn't run..

Here is terminal output:

dima@dima-VivoBook-ASUSLaptop-X415JAB-X415JA:~$ '/home/dima/Desktop/MU4_242241603_Lin_23939_Pipewire Audio Driver(1)/MuseScore-Studio-4.4.0.242241603-x86_64.AppImage' -d 
/lib/x86_64-linux-gnu/libjack.so.0
/lib/x86_64-linux-gnu/libnss3.so
Warning: Ignoring WAYLAND_DISPLAY on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
[D] pw.context [pipewire.c:231 load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.log'
[D] pw.context [pipewire.c:115 open_plugin()] can't load /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: cannot open shared object file: Permission denied
[D] pw.context [pipewire.c:231 load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.cpu'
[D] pw.context [pipewire.c:115 open_plugin()] can't load /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: cannot open shared object file: Permission denied
[I] pw.context [pipewire.c:647 pw_init()] version 1.0.4
[D] pw.thread-loop [thread-loop.c:146 loop_new()] 0x62c279642400: new name:pw-driver-loop
[D] pw.context [pipewire.c:231 load_spa_handle()] load lib:'support/libspa-support' factory-name:'support.system'
[D] pw.context [pipewire.c:115 open_plugin()] can't load /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: /root/build_tools/pw-1.0.4/lib/spa-0.2/support/libspa-support.so: cannot open shared object file: Permission denied
[E] pw.loop [loop.c:67 pw_loop_new()] 0x62c2796a2ba0: can't make support.system handle: No such file or directory
/tmp/.mount_MuseScTyp4NK/AppRun: line 26:  3320 Segmentation fault      (core dumped) "${APPDIR}/bin/mscore4portabledev" "$@"

[MarcSabatella]

Same.

[rtbo]

rebased on master.
In regards to bugs reported by @DmitryArefiev, I can't reproduce.
I've tested the PR on freshly installed Ubuntu 22.04 and Debian 13, it works consistently on both, as well as on my Ubuntu 24.04.

[rtbo]

Buffer sizes below are problematic in a new way

@rtbo regarding this issue: can we limit the min size to this constant MINIMUM_BUFFER_SIZE (audiotypes.h)?

This is done. The code now bounds buffer size between MINIMUM_BUFFER_SIZE and MAXIMUM_BUFFER_SIZE.
It is still possible to force to a lower buffer size by setting e.g. PIPEWIRE_LATENCY env var.
This is in the design of pipewire. In my case, with PIPEWIRE_LATENCY=64/44100, it still runs but with many underruns.

[DmitryArefiev]

@rtbo Now it doesn't crash, but I don't have a sound during note input and playback doesn't start

Now all good.

@rtbo Sorry for the long delay.. but can you rebase again please?

[DmitryArefiev]

Tested on LinuxUbuntu24.04.2 LTS (Wayland) - All good. I have sound during playback and note input

[zacjansheski]

On Ubuntu 22.04

I have no sound on note input / preview and playback does not start

Sorry for the bad video, but this shows it working in Nightly and not working in this PR

https://drive.google.com/file/d/1jfWYilnk5NM-sWuLrOy2ccpHdvia0b_2/view?usp=sharing

[zacjansheski]

MuseScore_250211_095743.log

[rtbo]

MuseScore_250211_095743.log

Your log file doesn't include pipewire log (I don't know how to redirect pipewire log out of standard outputs).

Can you repeat your test with
./MuseScore-Studio-4.5.0.250460632-x86_64.AppImage -d > log.txt 2>&1
and post log.txt?

[rtbo]

For me it doesn't work anymore as well :-/

Everything is fine with 1024 buffer size (both 44100 and 48000 Hz).

Going to 512 is creating many issues:

• either no sound or extremely stuttering on note input
• playback is perfectly fine
• when I pause playback, the same note plays forever, stuttered. (sometimes it eventually stops)
• DEBUG_AUDIO in AudioBuffer::pop gives me many missed frames (except during playback)

@RomanPudashkin do you have any idea?
Not sure whether it is relevant here, but note that the driver won't always send you the number of frames requested by the user in the preferences. Pipewire has dynamic latency features and will adapt to the running environment, need of resampling etc.