Native pipewire backend

[darkdragon-001]

Is your feature request related to a problem? Please describe.
Reduce latency by supporting Pipewire directly.

Describe the solution you'd like
Add a native Pipewire backend.

Describe alternatives you've considered
Continue using PulseAudio backend in combination with pipewire-pulseaudio conversion.

Additional context
Add any other context or screenshots about the feature request here.

[JasonLG1979]

I looked into writing a native pipewire backend a while back briefly just out of curiosity but at the time the Rust pipewire bindings were not the greatest (they may have improved since?).

Reduce latency by supporting Pipewire directly.

For pure playback latency is not really a problem. Super low audio latency is generally not a requirement unless you're recording and/or trying to live monitor recordings. What latency you would notice in librespot would be 99% network related, basically the delay between clicking a Spotify UI and librespot reacting. Reducing audio latency is not going to improve that. Librespot already has sub one sec audio latency (in most cases) which is barely perceivable if at all.

If the main reason for wanting a pipewire backend is to reduce latency currently it's more trouble then it's worth. You're looking at shaving maybe literally a couple millisecs and a lot of work for really no reason other than having the shiniest new thing.

Continue using PulseAudio backend in combination with pipewire-pulseaudio conversion.

The ALSA backend should also work just fine. Pipewire has compatibility layers for both.

[darkdragon-001]

Maybe you could give it another try and see if the libraries have improved since?

PipeWire can achieve lower latency with much less CPU usage and dropouts compared to PulseAudio.

~ Pipewire FAQ
So this could improve battery usage on mobile devices as well.

[JasonLG1979]

Maybe you could give it another try and see if the libraries have improved since?

I don't have the need. I use librespot with the ALSA backend. I have no need for middleware. You or anyone else (including the spot devs) are free to write a pipewire backend.

~ Pipewire FAQ
So this could improve battery usage on mobile devices as well.

Now you're reaching for straws. The FAQ says that pipewire provides pro level latency with consumer level power efficiency not that pipewire saves power over pulseaudio. Any measurable power savings you would get would be from switching from pulseaudio to pipewire on a server level. I seriously doubt that there would be any measurable power savings by switching librespot to a pipewire backend. Librespot is extremely light weight as is (it uses 10% CPU on my Pi Zero v2). If you want more power efficiency use the ALSA backend and cut out the middle man.

I agree that pipewire is the future of Linux desktop audio but the urgency is just not there to justify yet another audio backend for librespot when the ALSA and pulseaudio backends work just fine in pipewire.

[JasonLG1979]

In the case of something like spot they would be better served IMHO to just use librespot for the API bits and write their own player parts that use GStreamer rather then using librespot's player and backends. That way they could just target Gstreamer's APIs that are better suited for desktop app usage and they would get ALSA/pulseaudio/pipewire integration for free afterwards. That's what you would do normally for a desktop app.

[darkdragon-001]

In the case of something like spot they would be better served IMHO to just use librespot for the API bits and write their own player parts that use GStreamer rather then using librespot's player and backends. That way they could just target Gstreamer's APIs that are better suited for desktop app usage and they would get ALSA/pulseaudio/pipewire integration for free afterwards. That's what you would do normally for a desktop app.

This is a good hint! I created a corresponding issue xou816/spot#600

[JasonLG1979]

I didn't mean just switching to the Gstreamer librespot backend. I mean writing their own Gstreamer based player logic. The current librespot Gstreamer backend just handles playback of the decoded PCM, it doesn't utilize even a fraction of Gstreamer's potential. A completely Gstreamer based player would handle basically everything from decoding, playlists, eq's, volume normalization and whatnot. Not the same thing at all.

[darkdragon-001]

What would be the advantage of writing own gstreamer player logic instead of using librespot's gstreamer implementation apart from having more options to control?

[JasonLG1979]

The player and backends are designed for a cli app use case and are really more example then something meant to be used downstream. The general idea is that someone should write their own player. In the case of a Linux desktop app it's pretty natural to choose Gstreamer since it's the defacto multimedia framework in that space.