[unpo]

Running kodi-gbm-gles with pipewire (libpipewire 0.3) as audio backend on up-to-date arch linux on a NUC12.
Kodi Media Center 21.0-BETA2 (20.90.821) Git:20231227-0ac3c88709d-dirty

in kodi system audio: selected default pipewire device, best match

pipewire.conf:

    default.clock.rate          = 96000
    default.clock.allowed-rates = [ 44100 48000 88200 96000 ]

wireplumber/main.lua.d/50-alsa-config.lua:

    ["audio.allowed-rates"]      = "44100,48000,88200,96000",

I expected the samplerate to change when selecting a 44100 flac, similar to when having bare alsa as a backend (KODI_AE_SINK=ALSA) and the SPDIF USB (?) device selected.  

The kodi.log shows the CActiveAESink trying its best to make it happen:

https://paste.kodi.tv/qoditafiqu

But the samplerate stays at 96000 on the alsa_output device:

S   ID  QUANT   RATE    WAIT    BUSY   W/Q   B/Q  ERR FORMAT           NAME
R   41   1024  96000 963.5us  24.9us  0.09  0.00    0    S32LE 2 96000 alsa_output.usb-miniDSP_miniDSP_Flex-00.analog-stereo
R   51    735  44100 125.3us 690.7us  0.01  0.06    0    F32LE 2 44100  + Kodi

For comparison I tried MPV from a tty with pipewire backend, which does result in the expected change of the samplerate in the hardware:

R   40    256  44100 121.1us  11.0us  0.02  0.00    0    S32LE 2 44100 alsa_output.usb-miniDSP_miniDSP_Flex-00.analog-stereo
R   51       0  44100  47.5us   6.4us  0.01  0.00       0   S16LE 2 44100  + mpv

Having passed PIPEWIRE_DEBUG=4 to kodi, journalctl shows

https://paste.kodi.tv/sedaxadimo

[fritsch]

Kodi opens in 44.1 khz as ou see in your example with the pipewire default device. The rest is your configuration. What can kodi do on top?
As you cut yourlogfile ... I cannot tell you which devices were found and enumerated.

Also as you did not provide your mpv command line nor configuration, one can only speculate if you prefixed a specific device.

[unpo]

kodi.log, from starting up to exiting, in there selecting a track, playing it, stopping it:

https://paste.kodi.tv/mutetufoto.kodi

mpv session right after that, from tty:

https://paste.kodi.tv/uhohupukef

[fritsch]

MPV outputs 16 bit signed integer, so it decode the audio to floatp, converts it to signed 16 bit and pipewire decides: Let's use that as output.
Kodi decodes the output to float and as pipewire accepts this, it outputs it directly (in 44.1 khz (!)) without further conversion but pipewire then decides to keep the samplerate (its 96000) internally as it needs to touch the float bits anyways.

You should see that in your pipewire log. This is how a soundserver should behave. Kodi is just a client. There is one difference: When kodi has PT sinks, then pipewire switches. Other than that - all works as it should.

If you want to force the switch of the samplerate inside the backend, configure pipewire that way.

[fritsch]

So - as you don't seem to like the soundserver behavior (wondering why you use it), you could change kodi to enable: flags = static_cast<pw_stream_flags>(PW_STREAM_FLAG_EXCLUSIVE | static_cast<int>(flags)); always ... that way pipewire would basically try to be "as alsa" as possible ;-)

For the other change: Backend configuration overrules kodi's choice.

 diff --git a/xbmc/cores/AudioEngine/Sinks/pipewire/AESinkPipewire.cpp b/xbmc/cores/AudioEngine/Sinks/pipewire/AESinkPipewire.cpp
index bc5e3d3f96..8aa8d2eeb6 100644
--- a/xbmc/cores/AudioEngine/Sinks/pipewire/AESinkPipewire.cpp
+++ b/xbmc/cores/AudioEngine/Sinks/pipewire/AESinkPipewire.cpp
@@ -442,7 +442,7 @@ bool CAESinkPipewire::Initialize(AEAudioFormat& format, std:tring& device)

pw_stream_flags flags =
static_cast<pw_stream_flags>(PW_STREAM_FLAG_AUTOCONNECT | PW_STREAM_FLAG_INACTIVE |
- PW_STREAM_FLAG_MAP_BUFFERS | PW_STREAM_FLAG_DRIVER);
+ PW_STREAM_FLAG_MAP_BUFFERS | PW_STREAM_FLAG_DRIVER | PW_STREAM_FLAG_EXCLUSIVE);

if (!passthrough)
{

[unpo]

It is not that I don't like the Pipewire behaviour, I just don't quite grasp what's going on. I did not know that the default behaviour of Pipewire is to resample everything to it's set default rate, except, between the only two apps I've played with, when it's offered by mpv. 

I'll dig some more into this and thank you for the advice.

[fritsch]

Behaviour is not only samplerate specific. Also the format of choice plays an important role. And yeah, apps that send Float might habe different luck than apps that send 16 bit Integer. As Pipewire advertizes Float input format as well, we happily use this, as that's the default format after decoding with ffmpeg.

[fritsch]

You might want to open a bug report with pipe wire and link to our GitHub. If there is something on top Kodi can do to be more standard, upstream should tell us.

Thanks in advance.

[unpo]

If you want to force the switch of the samplerate inside the backend, configure pipewire that way.

Pardon my ignorance, you were also refering to PT sinks, for which I cannot find any other reference, would you be able to provicde any hints as to where to start to configure pipewire to force it to switch? I sor sure am going to try out the exclusive patch, but am also very interested in the more decoupled solution.

[fritsch]

There are exclusive formats handled by an AVR, among others DTS, AC3 or TrueHD, formats including Atmos bits. For these exclusive formats pipe wire will open the device if it is capable, exclusively.

In general those are the non PCM formats.

Arch wiki has an example iirc.

[unpo]

You might want to open a bug report with pipe wire and link to our GitHub. If there is something on top Kodi can do to be more standard, upstream should tell us.

Thanks in advance.

Missed this before my other reply. I will do this. Thank you.

[fritsch]

To complete:

For PCM formats where userspace has data it can cope with, the sound server is doing its job: making sure multiple sources can play in parallel. Resampling, format conversion is decided by the server only. Client won't have to know. Which is why I said that everything is fine from Kodi POV. We play our stuff in highest quality, Soundserver cares or does not care for the rest.

[unpo]

So - as you don't seem to like the soundserver behavior (wondering why you use it), you could change kodi to enable: flags = static_cast<pw_stream_flags>(PW_STREAM_FLAG_EXCLUSIVE | static_cast<int>(flags)); always ... that way pipewire would basically try to be "as alsa" as possible ;-)

I have modified AESinkPipewire.cpp 1) according to your diff, by introducing a local patch in my daily build environment and 2) I interpreted the 'enable flags always' to mean including that in the if (!passthrough) block so I did that, for experiment's sake. It did not result in any change in runtime. 

FYI: I posted this query on the pipewire issuetracker: https://gitlab.freedesktop.org/pipewire/...ssues/3747

[unpo]

Even more fun. Not in the standard client.conf file, but an available pipewire parameter as shown in the logs is "resample.disable" and setting this to true results in a hard failure, see log. I assume this is because of the float to int conversion required and because of the mandatory float to int conversion it feels it must resample the rate to the default rate and not keep the source samplerate intact. I also assume you've been trying to tell me this all this time. 

https://paste.kodi.tv/widuwovijo

[fritsch]

If that is the case, try removing AE FMT Float format in EnumerateDevicesEx ...