pipewire alsa missing configurations on multi output systems

[Lukas Wiest]

I have this bug also if I install pipewire manaully on focal and jammy.

I use a Java Application using the javax.sound package to get a output to the AudioSystem.
I have an own Java library using the same and I poked around a bit:

It uses Alsa as Output. The line object Java provides has the possibility to ask for the available bytes in the buffer. Normally with pulseaudio you can see the buffer getting filled and then, as the audio get's played back, recovering by the played back bytes amount.

With pipewire-pulse on the other hand it just fills the buffer and reporting no more available bytes. But it plays back the bytes successfully written to the buffer. Meaning its unable to write more, as the available buffer size never recovers, even though the already written ones have been played just fine.

I have checked the behavior also on Debain-testing, Manjaro and Fedora. Fedora is the only distro without this problem.
Fedora has the package pipewire-alsa in its repositories and installed, which is not available on the other distros. If I have understood it correctly, the alsa functionality should be included into the default pipewire-pulse now, but for some reason fedora decided to keep the extra package?

So I'd really like to see pipewire-pulse being the default in the future, but this has to be fixed somehow.

For reference, here's an issue on the pipewire gitlab I've filed already about this:
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2255

ProblemType: Bug
DistroRelease: Ubuntu 22.10
Package: pipewire-pulse 0.3.48-1ubuntu1
ProcVersionSignature: Ubuntu 5.15.0-27.28-generic 5.15.30
Uname: Linux 5.15.0-27-generic x86_64
ApportVersion: 2.20.11-0ubuntu82
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Thu May 26 14:58:40 2022
InstallationDate: Installed on 2022-05-26 (0 days ago)
InstallationMedia: Ubuntu 22.10 "Kinetic Kudu" - Alpha amd64 (20220525)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
SourcePackage: pipewire
UpgradeStatus: No upgrade log present (probably fresh install)

[Lukas Wiest (lukas-wiest)]

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.

[Sebastien Bacher (seb128)]

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

[Lukas Wiest (lukas-wiest)]

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.

[Lukas Wiest (lukas-wiest)]

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.

[Sebastien Bacher (seb128)]

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?

[Sebastien Bacher (seb128)]

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

[Lukas Wiest (lukas-wiest)]

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

[Sebastien Bacher (seb128)]

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

[Lukas Wiest (lukas-wiest)]

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.

[Lukas Wiest (lukas-wiest)]

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^^

[Launchpad Janitor (janitor)]

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

[Lukas Wiest (lukas-wiest)]

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.

[Dylan Aïssi (daissi)]

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

[Lukas Wiest (lukas-wiest)]

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.

[Dylan Aïssi (daissi)]

@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?

[Lukas Wiest (lukas-wiest)]

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?

[Sebastien Bacher (seb128)]

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/.