FS#77341 - [kodi] Compile with PipeWire support

Attached to Project: Community Packages
Opened by Mark Rietveld (WinterStar) - Tuesday, 31 January 2023, 08:21 GMT
Last edited by Ike Devolder (BlackEagle) - Monday, 20 February 2023, 20:04 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Ike Devolder (BlackEagle)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Kodi version 20.0 from the official Community repo seems to be compiled without PipeWire support:
The outputs listed under System - Audio are only PulseAudio and ALSA.
An attempt can be made to simply force PipeWire as the audio output by setting the environment variable KODI_AE_SINK=PULSEAUDIO, however this causes Kodi to not enumerate any audio devices at all on startup.
PipeWire support might be really useful since currently Kodi seems to lose an HDMI device as an output when such an HDMI device is powered off and on again. I suspect PipeWire as an output may alleviate that.
This task depends upon

Closed by  Ike Devolder (BlackEagle)
Monday, 20 February 2023, 20:04 GMT
Reason for closing:  Fixed
Additional comments about closing:  depend on libpipewire since kodi 20.0-6
Comment by Ike Devolder (BlackEagle) - Tuesday, 31 January 2023, 16:05 GMT
Thanks, I forgot about pipewire
Comment by Geert Hendrickx (ghen) - Wednesday, 01 February 2023, 05:38 GMT
This broke my audio, as kodi now uses Pipewire unconditionally (not configurable from the UI).
I had to start with KODI_AE_SINK=ALSA to make it work again. Using kodi-standalone-service from AUR.
Comment by Ike Devolder (BlackEagle) - Wednesday, 01 February 2023, 13:05 GMT
This would indicate that kodi could connect to pipewire since the fallback order is pulse -> pipewire -> alsa -> sndio

Does `systemctl --user mask pipewire.socket pipewire.service` help to automatically drop to the alsa fallback?
Comment by Mark Rietveld (WinterStar) - Wednesday, 01 February 2023, 13:28 GMT
I was told (unfortunately just after the recompile) to add that full-blown PipeWire support / w passthrough was implemented only towards the Master branch.
Additionally, the order in which Kodi checks the outputs is indeed Pulseaudio->PipeWire->Alsa. With the proper PipeWire implementation in Master it is intended for PipeWire to become the default/first priority output at a point in the near future.
Comment by Geert Hendrickx (ghen) - Wednesday, 01 February 2023, 14:51 GMT
Indeed pipewire was started automatically through systemd socket activation (pipewire.socket). And doesn't work out of the box, thus breaking a common setup by default (I must add that I'm not familiar with Pipewire, but Alsa always worked out of the box).

For a typical standalone media box, ALSA is recommended for high quality and low latency audio: https://kodi.wiki/view/PulseAudio#FAQ
Pipewire is not even mentioned on the Kodi wiki, so it may indeed be a bit premature to add it to our build already? Unless it can work out of the box.

Regarding order of detection: https://github.com/xbmc/xbmc/pull/22644 , but I assume such changes will not be backported to v20 Nexus.
Comment by Ike Devolder (BlackEagle) - Wednesday, 01 February 2023, 16:24 GMT
The main issue with pipewire vs pulseaudio is, that pulseaudio comes with a libpulse package, where pipewire has everything on board, causing this issue. So I don't think the pipewire support is premature to have, but due to our way of packaging it becomes indeed pretty inconvenient to use default alsa without any intervention
Comment by Geert Hendrickx (ghen) - Wednesday, 01 February 2023, 16:53 GMT Comment by Geert Hendrickx (ghen) - Wednesday, 01 February 2023, 16:56 GMT
I confirm kodi falls back to using ALSA after `systemctl --global disable pipewire.socket` (which was enabled automatically when pipewire was installed as dependency).
Comment by Costas G (csts) - Friday, 03 February 2023, 03:22 GMT
I was using Pipewire with Kodi Matrix and had to close Kodi and restart it when it had no audio -sometimes I had to restart Pipewire too.
I read online that Kodi didn't support Pipewire yet, and there were no solutions.
So I installed Pulseaudio and forgot about it.

I installed Pipewire again a bit more than a week ago, and the only thing I had to do once in Kodi was reset to Defaults in Settings > System > Audio.

Seems like both Nexus and Matrix (v19.4 via Flatpak downgrade) now work with Pipewire without issues.
Comment by Aaron Barany (akb825) - Saturday, 11 February 2023, 20:42 GMT
After updating to the latest version of Kodi, audio is completely broken. GUI sounds play initially, but as soon as I play anything playback freezes and no sound is output, even GUI sounds. Trying to exit kodi normally hangs and the process needs to be killed. Using the KODI_AE_SINK=ALSA environment variable appears to have restored functionality.
Comment by Chad Stern (complexlogic) - Saturday, 18 February 2023, 17:12 GMT
Another confirmation of the audio issues reported above. I was previously using a self-built Nexus alpha release and just upgraded to the official Arch build of Nexus. Audio was completely broken with no option to adjust in the GUI, and setting the environment variable before startup fixed the problem.

ALSA is superior for single use applications such as an HTPC, and should not require special configuration with environment variables to use it.

I noticed that the PKGBUILD no longer has the '-DENABLE_ALSA=ON` CMake option.
Comment by Geert Hendrickx (ghen) - Saturday, 18 February 2023, 17:15 GMT
(sudo) systemctl --global disable pipewire.socket (+reboot) fixes the problem too. I think the pipewire package installation shouldn't automatically enable it, the user should do this explicitly if he intends to, like most other services/daemons.
Comment by Ike Devolder (BlackEagle) - Monday, 20 February 2023, 15:32 GMT
Chad: Yeah the ALSA and PULSE enablement flags were removed since the cmake implementation of the audio engines is somewhat inconsistent, you can enable ALSA and PULSE, but pipewire is only autodetect

Geert: I'll move this pipewire split into a lib and pipewire itself and if default enabling should be done into a new issue https://bugs.archlinux.org/task/77584
Comment by Geert Hendrickx (ghen) - Monday, 20 February 2023, 19:20 GMT
Solution confirmed (I force-removed pipewire leaving only the split libpipewire package). Thanks Ike!

Loading...