pipewire alsa missing configurations on multi output systems

Update (see the pipewire ticket linked in the OP):

Issue can be fixed by cleaning out interfering configuration from /etc/alsa/conf.d ensuring that Alsa client directly use Pipewire instead of Pulse.

Thank you for the update. So the problematic configuration was one you created or was it installed by some of the packages?

It's the state after a fresh installation.

For 20.04 & 22.04 that's not great but I guess I've to live with it, that if one wants to switch to Pipewire has to take care of these configs.

But it's the same on a fresh 22.10 install without customization anywhere, which wants to have Pipewire as default.
After clearing the alsa configs it is fixed.

After a little more testing I can pin it down to the preinstalled /etc/alsa/conf.d/99-pulse.conf being the culprit. Removing this, leaving everything else preinstalled in place and adding the files for Pipewire (50-pipewire.conf and 99-pipewire-default.conf) is enough to get it working properly.

The file is provided by pulseaudio, which shouldn't be installed if you intend to use pipewire as a sound server, maybe we should make pipewire-pulse and pulseaudio conflicts?

Reported to Debian now as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013276

Hey short feedback from my side:

I made a fresh install of the daily downloaded on 2022-06-21.
Pulseaudio is not preinstalled anymore, the /etc/alsa folder completely non-existent.
This makes it at least not break fully, but still not working quite right.

So, installing it in a VM, having just one audio device at all this works fine.

But installing it on my actual hardware leaves the alsa use always an output one off from what's selected in the system settings, resulting in either sound comes out of the wrong output or isn't audible at all as it's trying to access an output out of index.

Solution for this was to
- install pipewire-audio-client-libraries (which creates a /etc/alsa/conf.d/50-pipewire.conf)
- copy or link /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf to /etc/alsa/conf.d

Only installing pipewire-audio-client-libraries wasn't enough, the 99-pipewire-default.conf was needed as well.
After that the output of Alsa applications lines up with the system settings choosen one

Thanks. The package description for pipewire-audio-client-libraries states

'They are not used by default, and are currently considered to be experimental.'

I don't know if that's still the current status from an upstream perspective though

I'm not sure if the package itself is needed, but it brings the 99-pipewire-default.conf into the /usr/share/doc to be copied over to /etc. Probably it's enough to have the config file in place, but not the client-libs package installed.

Hey, are there any changes in the making to at least by default place the needed config to /etc/alsa/conf.d if the switch to pipewire stays for 22.10?

If not, that would mean that users with various outputs (like in my case built-in speakers, HDMI and USB-Hub) won't have alsa clients use the correct sink^^

This bug was fixed in the package pipewire - 0.3.58-2ubuntu1

---------------
pipewire (0.3.58-2ubuntu1) kinetic; urgency=medium

  * New bugfix version synced from Debian, including packaging changes
    to create a new pipewire group allowing realtime priority. Users
    don't get added to that group by default. (ffe lp: #1990313)
  * Include the fix to ensure the the service is started after the
    session manager, otherwise no device is listed (lp: #1992101)
  * Revert 'Let pipewire-pulse conflicts on pulseaudio' since it's late
    for that change, we will revisit doing that next cycle

pipewire (0.3.58-2) unstable; urgency=medium

  * Mention to install pipewire-alsa and pipewire-jack
      in README.Debian (Closes: #1019971)
  * Add debian/pipewire-alsa.TODO
  * Patch pipewire-pulse.service to be sure it is started
      after a session manager (Closes: #1019944)
    Because of a bug in the way systemd handles aliases, they have been removed
    in wireplumber and pipewire-media-session services to avoid a conflict.
    This change needs to be reflected in the pipewire-pulse service to be sure
    it is started after a session manager, otherwise pipewire-pulse doesn't
    see any devices.

pipewire (0.3.58-1) unstable; urgency=medium

  [ Dylan Aïssi ]
  * New upstream release
      - Fix crackling sound if pavucontrol is open (Closes: #1019888)
  * Create a pipewire group and define real-time priority limits
      (Closes: #1011399)
  * Add suggestion to install wireplumber in pipewire.README.Debian
  * Clarify relation between pipewire and libspa-0.2-bluetooth in
      pipewire.README.Debian (Closes: #998220, #1011035)
  * Remove reference to experimental status of pipewire for audio

  [ Sebastien Bacher ]
  * Let pipewire-pulse conflicts on pulseaudio
      (Closes: #1013276, LP: #1975823)

 -- Sebastien Bacher <email address hidden> Fri, 07 Oct 2022 16:38:13 +0200

Ok I downloaded the Kinetic-daily installation iso from 2022-10-12 and made a fresh install and checked that pipewire version is 0.3.58-2ubuntu1

But: The situation didn't really change from what I described in #8 already.
The audio is working fine in a VM, where all goes through the one available audio sink.
Installing it on actual hardware, where suddenly the laptop, the dock and the HDMI is available as output Alsa applications get confused.

Solution is still the same: Install the pipewire-audio-client-libraries and copy over the conf file from the example folder, after that Alsa applications follow the selected audio output flawlessly.

So: I really would suggest just putting the two configurations by default into /etc/alsa/conf.d on system installation.

I feel this bug report is mixing several issues which makes it difficult to follow.

The bug description and the bug opened on the upstream side [0] relating to issues with alsa/java and buffer look very similar to [1-2] which have been fixed in pipewire 0.3.58 [3].

Then, in the next comments I see complaints about pipewire-alsa for which configuration files are missing. This is expected since pipewire-alsa has never been activated by default [4-5]. But, because pipewire now replaces pulseaudio, it would eventually make sense to install conf files in the right location to enable pipewire-alsa by default when it is installed.

By removing/adding/playing with pulseaudio/pipewire conf files, you probably made the sound go through a not buggy [3] path. But, I don't see a conflict between pulseaudio and pipewire here although I may be wrong. Other distros mark pulseaudio and pipewire in conflict without technical reason just for simplicity.

[0] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2255
[1] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2626
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2596
[3] https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/a79b5c86ea33d7103c07552ecbbde54e1c01e7bd
[4] https://wiki.debian.org/PipeWire#ALSA_and_JACK
[5] https://salsa.debian.org/utopia-team/pipewire/-/blob/debian/master/debian/pipewire.README.Debian

Hm, I guess I'm not deep enough in this stuff on the technical side that I'd have recognized this. My Problem simply was "application xyz doesn't work correctly without doing steps abc".

If there was an underlying bug fixed in 0.3.58 I couldn't tell, as it was working fine on previous versions already by adding the Alsa configuration.

So, my aim when opening this ticket was: I'd like to install Ubuntu and my Java applications should respect the Audio sink choice I did from the GUI as expected, which it only does if the Alsa configuration for routing it through Pipewire is present.

@Lukas You did your part of the job by complaining here :-). If nobody files bug report then we cannot fix bugs. I was just trying to figure out and summarize what happened and what we need to do to improve your user experience.

To be sure, the only remaining part here is to install the pipewire-alsa config files in the right location, then we can close this bug report?

Yeah, you're right. But after I re-read the whole ticket (and especially the original report) I recognized I could have made a better job describing my actual problem and what the imagined fixed behaviour should be, instead of trying to find the cause myself.^^

Yes, if I add the configurations (which routes all Alsa output over Pipewire I guess?) the applications are behaving as intended, following the global system selected sink and volume.

And as far as I can tell, this was the default configuration of Ubuntu in the past with Pulseaudio for Alsa applications as well, but was just missed to do with Pipewire on the transition?

The issue is fixed in lunar with that change from Debian

  * pipewire-alsa: conflict with pulseaudio. (Closes: #1013276)
      As long as the pulseaudio package is installed, ALSA clients will output
      via PulseAudio instead of PipeWire. This is due to the order of their
      respective configs files in /etc/alsa/conf.d/.