audio: Prefer Pipewire over Pulseaudio (take 2)

[Kontrabant]

If SDL is configured with both Pipewire and Pulseaudio support, this adds a preferred Pipewire bootstrap entry that uses DBus to query if the pipewire-pulse service exists and is in the "running" state. If it is, then it is certain that Pipewire is being used instead of Pulseaudio as the preferred system mixer and will be preferred over Pulseaudio. If DBus support is not enabled or Systemd is not being used on the underlying system, this check will simply fail and the standard driver order will be tested as before.

While still not 100% flawless, it is currently the best method for detecting if Pipewire is the preferred mixer for the system, as other possibilities have drawbacks:

• Simply checking for sinks/sources won't work, as Pipewire can still be used to mix audio and lists sinks/sources, even if the system is also running the real Pulseaudio server.
• Using pactl to dump the info string and look for "pipewire" requires that the user installed the Pulseaudio utilities, which typically aren't installed by default, and that their behavior is never altered.

Closes #8788

cc @flibitijibibo @icculus

[flibitijibibo]

Makes sense to me - I guess we should sync this with the Wayland preference change to make sure the bootstrap logic all matches?

[icculus]

Yeah, this is clever. I haven't looked at what the Wayland stuff does that we could sync up here, but take a look at that and see if it's worth it before we merge this.

[flibitijibibo]

Posted in the Wayland thread, aside from that this should be good to go (IMO).

[icculus]

Yeah, I think the Wayland stuff should match this.

Okay, last call before I pull the trigger on merging this, then!

[swick]

This is broken in a lot of environments, including flatpak which is arguably the most common environment SDL will run in.

The name of services is not stable, access to the session bus is restricted. This change is overall just a really bad idea and SDL_DBus_QuerySystemdUnitRunning should be thrown away.

Checking for the pipewire socket should be much more robust and give you the same behavior. Usually if the pipewire socket exists, the pulse socket also comes from pipewire.

[slouken]

@swick, can you open an issue on this for tracking?

[swick]

#9543

[slouken]

Thanks!