Linux audio broken after update to float

[cfalas]

Is there an existing issue for this?

• I have searched the existing issues

Is your issue described in the documentation?

• I have read the documentation

Is your issue present in the latest beta/pre-release?

This issue is present in the latest pre-release

Describe the Bug

After pull #2873, audio on my system stopped working. More precisely, audio is cracking, and if I know what I'm listening to I can barely make out the rhythm in music for example.

Someone else also has the same issue and there have been some more details on Discord https://discord.com/channels/804382334370578482/1270794178413985968 (along with audio samples)

Expected Behavior

Audio is clear

Additional Context

If relevant, this is an issue with both Pipewire 1.2.2 and 1.2.1, but haven't tried downgrading any of the deps of pipewire.

Host Operating System

Linux

Operating System Version

Arch Linux, kernel 6.10.2

Architecture

64 bit

Sunshine commit or version

v2024.808.10128-1

Package

Linux - AUR (Third Party)

GPU Type

Intel

GPU Model

UHD 770

GPU Driver/Mesa Version

24.1.5

Capture Method

wlroots (Linux)

Config

adapter_name = /dev/dri/renderD128
output_name = 0
resolutions = [
    352x240,
    480x360,
    858x480,
    1280x720,
    1920x1080,
    2560x1080,
    3440x1440,
    1920x1200,
    3840x2160,
    3840x1600,
    2960x1848
]
channels = 2

Apps

No response

Relevant log output

[2024:08:08:20:29:42]: Info: Opus initialized: 48 kHz, 2 channels, 512 kbps (total), LOWDELAY

[cfalas]

I know there isn't much info to go off of, let me know if there's anything else I can provide

[ns6089]

added audio:pipewire and removed audio:pulseaudio

It's both pipewire and pulseaudio to be honest. Sunshine only talks to pulseaudio, pipewire provides its own api-compatible pulseaudio server implementation. But evidently doesn't copy it perfectly.

Will try to look into this a bit later I guess. It either creatively interprets buffer sizes or can't do floating point sinks properly, but the latter would be rather stupid.

[cfalas]

Can confirm that changing pipewire to pulseaudio on my system fixes the problem, so it's definitely some misinterpretation in the pipewire implementation of pulse

[goncalossilva]

The issue is reproducible on a fresh installation of Bazzite (or Fedora, most likely) which uses pipewire by default, and switching back to pulseaudio is also a viable workaround there too:

rpm-ostree override remove pipewire-pulseaudio --install pulseaudio

[ns6089]

Unable to reproduce this on Arch Linux with latest pipewire-pulse
Does it require some extra steps like putting system under load?

[ns6089]

Either way #2999 should hopefully fix this, but I can't say for sure because I can't reproduce the cracking in the first place.

[cfalas]

I don't think there's any other steps required, but #2999 does seem to fix the issue for me.