Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Dylan Aïssi]

Hi Wouter,

Le mer. 5 oct. 2022 à 09:21, Wouter Verhelst  a écrit :
>
> I'm not familiar enough yet with pipewire to know which tools to use to
> debug what went wrong. Can you point me to the relevant docs? Once I
> have a better idea of what went wrong, expect a bug report coming your
> way ;-)
>

You can find the upstream troubleshooting guide here:
  https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting

I should add a paragraph about that on our wiki.

In any case, feel free to open a "it doesn't work" bug against the pipewire
package :-)

Best,
Dylan

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Wouter Verhelst]

Hi Dylan,

Something in pipewire caused my laptop to lose all audio. Since I work
remotely and need to attend meetings over various video conferencing
tools, that was not an option for me, so I reverted back to pulseaudio
by removing everything from src:pipewire from my laptop and rebooting,
which seems to have "fixed" the issue.

Obviously however, this can't be the right long-term solution, but I
don't know exactly what went wrong.

When I opened an ALSA mixer tool, the mixer was set to 0, and moving it
up would work but then restarting the mixer tool would show it was at 0
again.

Opening pavucontrol would show a single device, called "dummy audio
device" (paraphrasing), with no way to select another device.

I'm not familiar enough yet with pipewire to know which tools to use to
debug what went wrong. Can you point me to the relevant docs? Once I
have a better idea of what went wrong, expect a bug report coming your
way ;-)

Thanks,

On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.
> 
> As you know, PipeWire is already installed by default with Bullseye (at least
> with Wayland environments) for screen-sharing. PipeWire was not mature enough
> to use it as default sound server for Bullseye, but since it gained in
> stability, features and popularity. Several other major distributions
> (Fedora, Ubuntu is doing the switch with 22.10) have switched to PipeWire
> for audio [1-3].
> 
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.
> 
> BTW, I just uploaded latest PipeWire and WirePlumber in bullseyes-backports
> (still in the NEW queue) to allow more users to test them.
> 
> Best,
> Dylan
> 
> [1] https://fedoraproject.org/wiki/Changes/DefaultPipeWire
> [2] https://fedoraproject.org/wiki/Changes/WirePlumber
> [3] https://wiki.ubuntu.com/ImpishIndri/ReleaseNotes
> [4] 
> https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/
> 
> 

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Emanuele Rocca]

On 2022-09-29 01:41, Simon McVittie wrote:
> It's fine to control Pipewire via PulseAudio's IPC protocol (that's what
> gnome-control-center and gnome-shell do!) and if that doesn't work,
> then it means pipewire-pulse is not fully doing its job.

Is it fine, or is it a necessity? What I understand from your reply is
that (by design or de facto) PulseAudio's compatibility layer is *the*
way to control Pipewire, at least in gnomeland.

If that is the case, it may be a good idea to let our users know. A
note in the wiki is probably enough! Someone else could be confused
when they find out that PulseAudio is still around despite the migration
to Pipewire. I'm happy to do the writing, once I figure out what to
write.

> Switching to a different sound server implementation shouldn't require
> rewriting every graphical and TUI/CLI mixer/control utility, if the
> compatibility layer is good enough.

Agreed. When we discover the irreparable design flaws of Pipewire and
come up with a replacement though, it would be nice to have *one*
compatibility layer, instead of one per sound server implementation
replacement. :-)

> If you prefer to use CLIs, pw-cli is a low-level CLI for Pipewire, and
> wpctl is a somewhat higher-level CLI for Wireplumber; they're analogous
> to PulseAudio's pacmd and pactl.

Very nice, thank you.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jonathan McDowell]

On Sun, Oct 02, 2022 at 07:29:31PM +0100, Jonathan McDowell wrote:
> On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> > Hi,
> > 
> > I have been asked several times regarding when Debian will switch its 
> > default
> > sound server from PulseAudio to PipeWire without having an official answer.
> > Thus, I suppose it's the right time to start a discussion about that.
> 
> Perhaps, now this has actually got as far as testing, someone will be so
> kind as to at least comment on #996750, which I opened almost a year
> ago. It's had no follow-ups and I'm now seeing the same behaviour on a
> system that only has an external screen - it doesn't actually go into
> power save mode. I suspect there's something going on with pipewire and
> HDMI audio, but it's a regression from a pulseaudio setup.

After a bit more patience, and some experimentation, I'm going to have
to recant. It might be taking a _little_ longer to actually hit power
save, but it is now happening and it does seem to recover ok.

Apologies for the noise, I'll follow up to the bug.

J.

-- 
   101 things you can't have too   |  .''`.  Debian GNU/Linux Developer
   much of : 33 - Jokes.   | : :' :  Happy to accept PGP signed
   | `. `'   or encrypted mail - RSA
   |   `-key on the keyservers.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jonathan McDowell]

On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> Hi,
> 
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.

Perhaps, now this has actually got as far as testing, someone will be so
kind as to at least comment on #996750, which I opened almost a year
ago. It's had no follow-ups and I'm now seeing the same behaviour on a
system that only has an external screen - it doesn't actually go into
power save mode. I suspect there's something going on with pipewire and
HDMI audio, but it's a regression from a pulseaudio setup.

J.

-- 
If we sleep together, will you like me better?

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Wouter Verhelst]

On Thu, Sep 29, 2022 at 02:26:03PM +0200, Emanuele Rocca wrote:
> [1] I already have alsa, jack, pulseaudio, pipewire packages
> installed... At least no oss anymore! :)

Since OSS is completely in-kernel, you actually do :-)

(and yes, it still works. I own some ancient non-free games, they only
support OSS for audio, and are statically linked so the aoss stuff
doesn't work...)

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Stone]

On Thu, Sep 29, 2022 at 04:26:45PM +0200, Vincent Bernat wrote:

On 2022-09-29 15:01, Michael Stone wrote:

On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:

* Finally, I can use bluetooth on linux with reasonably good audio
 quality!


Aren't they both using the same backend? ldac/aptx weren't in 
pulseaudio for a long time, but they are now. Or is there something 
else?


Pipewire has AAC, but not in Debian because libfdk-aac is still 
considered non-free by us while everyone else, including the FSF, 
consider it free.


but that wouldn't be a distinction between pulseaudio and pipewire in 
debian, right?

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Simon McVittie]

On Thu, 29 Sep 2022 at 16:26:45 +0200, Vincent Bernat wrote:
> Pipewire has AAC, but not in Debian because libfdk-aac is still considered
> non-free by us while everyone else, including the FSF, consider it free.

See also . A version of fdk-aac that
moves it to main has been uploaded to NEW, where it has the dubious
distinction of being the package that has been in NEW for the longest
without being either accepted or rejected.

smcv

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-29 15:01, Michael Stone wrote:

On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:

* Finally, I can use bluetooth on linux with reasonably good audio
 quality!


Aren't they both using the same backend? ldac/aptx weren't in pulseaudio 
for a long time, but they are now. Or is there something else?


Pipewire has AAC, but not in Debian because libfdk-aac is still 
considered non-free by us while everyone else, including the FSF, 
consider it free.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Stone]

On Wed, Sep 28, 2022 at 09:02:15PM -0600, Sam Hartman wrote:

* Finally, I can use bluetooth on linux with reasonably good audio
 quality!


Aren't they both using the same backend? ldac/aptx weren't in pulseaudio 
for a long time, but they are now. Or is there something else?

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Clément Hermann]

On September 29, 2022 12:26:03 PM UTC, Emanuele Rocca  wrote:
>Hi,
>
>On 2022-09-08 05:58, Dylan Aïssi wrote:
>> I have been asked several times regarding when Debian will switch its default
>> sound server from PulseAudio to PipeWire without having an official answer.
>> Thus, I suppose it's the right time to start a discussion about that.
>
>PipeWire seems to be working just fine as a drop-in replacement for me
>on sid, so personally I don't have any objections to the sound server
>switch.
>
>My concern is about the availability of clients for controlling things
>like volume and which output device to use. In an effort to try and
>reducing the variety of sound-related stuff installed on my machines
>[1], I've removed everything vaguely resembling "pulseaudio", except for
>what would have caused the removal of tons of stuff. I am now left with:
>
>libpulse-mainloop-glib0:amd64
>libpulse0:amd64
>pipewire-pulse
>
>Sound still works fine, but how to do things like changing volume,
>toggling mute, choosing between HDMI and headphones, ...? I understand
>that one can still use pavucontrol, but that would essentially mean
>bringing back parts of pulseaudio (at least libpulsedsp, pavucontrol,
>and pulseaudio-utils).
>
>If it's true that pavucontrol (or similar) is still required, I think it
>would be a bit confusing to make the switch from pulseaudio to pipewire
>and still have functional dependencies on pulseaudio around.

You don't need to remove pulseaudio client stuff. It will work fine with 
pipewire (I do use pavucontrol for instance, despite having switched a while 
ago).

Only the pulseaudio daemon needs to be at least stopped.

Cheers,

-- 
nodens

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Simon McVittie]

On Thu, 29 Sep 2022 at 14:26:03 +0200, Emanuele Rocca wrote:
> Sound still works fine, but how to do things like changing volume,
> toggling mute, choosing between HDMI and headphones, ...?

Well-integrated desktop environments should have this built in (GNOME
certainly does).

If you're building your own desktop environment from smaller pieces,
then you've taken some of the responsibility for doing the necessary system
integration and finding a combination of components that works together.
Not all of them are necessarily going to come from the same upstream.

> I understand
> that one can still use pavucontrol, but that would essentially mean
> bringing back parts of pulseaudio (at least libpulsedsp, pavucontrol,
> and pulseaudio-utils).

It's fine to control Pipewire via PulseAudio's IPC protocol (that's what
gnome-control-center and gnome-shell do!) and if that doesn't work,
then it means pipewire-pulse is not fully doing its job. Switching to
a different sound server implementation shouldn't require rewriting
every graphical and TUI/CLI mixer/control utility, if the compatibility
layer is good enough.

If you prefer to use CLIs, pw-cli is a low-level CLI for Pipewire, and
wpctl is a somewhat higher-level CLI for Wireplumber; they're analogous
to PulseAudio's pacmd and pactl.

smcv

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Emanuele Rocca]

Hi,

On 2022-09-08 05:58, Dylan Aïssi wrote:
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.

PipeWire seems to be working just fine as a drop-in replacement for me
on sid, so personally I don't have any objections to the sound server
switch.

My concern is about the availability of clients for controlling things
like volume and which output device to use. In an effort to try and
reducing the variety of sound-related stuff installed on my machines
[1], I've removed everything vaguely resembling "pulseaudio", except for
what would have caused the removal of tons of stuff. I am now left with:

libpulse-mainloop-glib0:amd64
libpulse0:amd64
pipewire-pulse

Sound still works fine, but how to do things like changing volume,
toggling mute, choosing between HDMI and headphones, ...? I understand
that one can still use pavucontrol, but that would essentially mean
bringing back parts of pulseaudio (at least libpulsedsp, pavucontrol,
and pulseaudio-utils).

If it's true that pavucontrol (or similar) is still required, I think it
would be a bit confusing to make the switch from pulseaudio to pipewire
and still have functional dependencies on pulseaudio around.

ciao,
  ema

[1] I already have alsa, jack, pulseaudio, pipewire packages
installed... At least no oss anymore! :)

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Clément Hermann]

Le 29/09/2022 à 00:30, Lisandro Damián Nicanor Pérez Meyer a écrit :

Hi,

On Tue, 13 Sept 2022 at 13:39, Antoine Beaupré  wrote:
[snip]

I also have the feeling that pipewire has already gone beyond what
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.

Well, with pulseaudio I always needed to run the following each time I
log into KDE in order to be able to pair with my devices:

$ cat bin/restart_bluetooth.sh
#!/bin/sh

pulseaudio -k
start-pulseaudio-x11
sudo service bluetooth restart

I have tried pipewire and I have the same issue, but this time
restarting pipewire-pulse doesn't helps.

Of course the root cause of this might be even deeper that that, but
so far that's the only way I could make my BT devices to pair on my
laptop :-/


Try maybe restarting wireplumber instead (or as well)? It's involved in 
BT while pipewire-pulse isn't.


--
nodens

Jack client in PipeWire [was: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio]

[Clément Hermann]

Hi,

Le 29/09/2022 à 05:02, Sam Hartman a écrit :


* If you do need jackd for real because pipewire's jack isn't quite good
   enough, pipewire's jack client didn't work at all last time I used
   it.  So you may be forced to shut down wireplumber and pipewire and
   start up pulseaudio.

FWIW, I did manage to get a jack client in pipewire by setting

["alsa.jack-device"] = true

in the alsa_monitor.properties block of 
.config/wireplumber/main.lua.d/50-alsa-config.lua


It creates a jack_client device that you can set on or off.

In my case I did that because some librtaudio apps misbehave with the 
current pipewire jack emulation (VCV Rack in this case) if you don't 
force the sample rate/size and using native jack makes it better (since 
native jack doesn't allow live change of sample rate anyway).


HTH,

--
nodens

--
nodens

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Sam Hartman]

> "Dylan" == Dylan Aïssi  writes:

Dylan> We cannot talk about PipeWire without mentioning its session
Dylan> manager.  Thus, this change should go along the switch of the
Dylan> default session manager, i.e. from the deprecated
Dylan> pipewire-media-session to WirePlumber.  We still use
Dylan> pipewire-media-session as default session manager because it
Dylan> enables PipeWire *only* for screen-sharing and not for
Dylan> managing audio.  Whereas WirePlumber always configures
Dylan> PipeWire for audio excepted by modifying conf files in a
Dylan> non-compatible packaging way. This issues was also hit on the
Dylan> Arch Linux side [4]. This WirePlumber behavior may be solved
Dylan> in the next major release 0.5 planned later this year.

I would really like to see bookworm with pipewire and wireplumber.

Major advantages:

* I find pipewire is much more likely than pulseaudio to do something
  sane when there are multiple potential sound devices and when sound
  devices are added/removed.

* Finally, I can use bluetooth on linux with reasonably good audio
  quality!

* pw-jack is good enough for some jack use cases, and is so much easier
  to deal with than jackd plus jack-sink and jack-source.

The disadvantages:

* pw-jack isn't really good enough for all my JACK use cases.  Doing
  network audio doesn't really work well, even given the various options
  on the pipewire wiki.

* I find that MIDI gets into a very unfortunate state when I crash a
  jack client sometimes and I end up having to restart pipewire and
  wireplumber to recover.
  I have not been able to articulate reproducing conditions enough to
  file a useful bug report.

* If you do need jackd for real because pipewire's jack isn't quite good
  enough, pipewire's jack client didn't work at all last time I used
  it.  So you may be forced to shut down wireplumber and pipewire and
  start up pulseaudio.

My jack/pulse needs are kind of complicated because I do need system
audio for my screen reader and realtime audio for my music.  And
unfortunately when performing live, I do need to mix the screen reader
audio into my performance headphones, which means I need to get audio
from the pulseish side into the jackish sideof things.  Which is to say
that I cannot isolate jackd from pipewire/pulseaudio.

I agree with everyone who suggests switching sooner rather than later.

Re: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Lisandro Damián Nicanor Pérez Meyer]

Hi,

On Tue, 13 Sept 2022 at 13:39, Antoine Beaupré  wrote:
[snip]
> I also have the feeling that pipewire has already gone beyond what
> pulseaudio is capable of in terms of Bluetooth support, but I might be
> mistaken on that.

Well, with pulseaudio I always needed to run the following each time I
log into KDE in order to be able to pair with my devices:

$ cat bin/restart_bluetooth.sh
#!/bin/sh

pulseaudio -k
start-pulseaudio-x11
sudo service bluetooth restart

I have tried pipewire and I have the same issue, but this time
restarting pipewire-pulse doesn't helps.

Of course the root cause of this might be even deeper that that, but
so far that's the only way I could make my BT devices to pair on my
laptop :-/

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Lefevre]

On 2022-09-08 17:58:25 +0200, Dylan Aïssi wrote:
> We cannot talk about PipeWire without mentioning its session manager.
> Thus, this change should go along the switch of the default session manager,
> i.e. from the deprecated pipewire-media-session to WirePlumber.
> We still use pipewire-media-session as default session manager because it
> enables PipeWire *only* for screen-sharing and not for managing audio.
> Whereas WirePlumber always configures PipeWire for audio excepted by modifying
> conf files in a non-compatible packaging way. This issues was also hit on
> the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
> major release 0.5 planned later this year.

In the case WirePlumber is used, what is the status of bug 998073?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998073
  wireplumber: fails to automatically switch to headphones when connected

(which is an issue for those who use both speakers and headphones
and want to automatically switch between them). The upstream bug

  https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/267

is still open and users are still reporting problems. There is no such
issue with PA.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jeremy Bicha]

On Sun, Sep 18, 2022 at 4:53 PM Diederik de Haas  wrote:
> I think there currently aren't that many Debian users which do use PW and I
> think that switching the default audio provider in all of Debian (not just
> Gnome) is FAR more involved then the impression I got from this ML thread.

At least on my part, this discussion is only about GNOME,
specifically, the gnome-core package and probably
gnome-settings-daemon.

You're still able to keep using PulseAudio especially if you are using
other desktops. I don't know when and if other Debian desktops will
switch because I'm not involved in those decisions.

I'll likely upload the gnome-core change to Unstable tomorrow.

Thank you,
Jeremy Bicha

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Diederik de Haas]

On 23 February 2022, I wrote this in https://bugs.debian.org/999363#35:

On 23 Feb 2022 17:21:29 +0100 Diederik de Haas  wrote:
> On 10 Nov 2021 15:40:21 +0100 Sebastien Bacher  wrote:
> > Switching the default sound service is an option but should probably be 
> > a project discussion and not a consequence of a dependency tweak.
> 
> Is that discussion taking place somewhere? If so, where?
> If not, then shouldn't that discussion start ASAP?
> 
> The discussion itself will likely take some time and if the decision is made 
> to do the switch, then it could very well be that various upstream changes 
> should take place (where it hasn't already) and then also Debian packages
> need to be updated.
> 
> I don't know exactly when the Freeze for Bookworm is scheduled, but assuming
> a 2 year release cycle, we now have ~ a year to make that switch happen and 
> suitable for a Stable release.
> If we wait another 6 months or so, it'll become really problematic and we'd 
> have to carry the technical debt likely into Trixie.

I thought ~ a YEAR to make the transition _should_ be doable.
But now that 2/3 of that have passed, I think it would be a mistake to switch 
the default from PA to PW+WP.

On Thu, 26 Aug 2021 11:56:05 +0200 Dylan Aïssi  wrote:
> The best way to deal with that issue is to update all packages that
> Depends, Recommends or Suggests pulseaudio to depend either on
> pulseaudio or pipewire-pulse (i.e. pulseaudio | pipewire-pulse).

This is from more then a YEAR ago and AFAIK very little work on that has been 
done.

Here are some more 'tidbits' from me:
- pipewire-media-session (as session manager) was already deprecated upstream 
since the beginning of the year. It was already then strongly urged to switch 
to WirePlumber, but that has still not been done in Debian
- I saw several references to Wayland and Gnome. Keep in mind there are other 
Desktop Environments. Some 'daredevils' are (sometimes) trying Wayland with 
KDE and IIUC, it'll be a while before anyone can safely switch to using it.
- IIUC/IIRC, even the RTKit maintainer doesn't (really) want to touch the code 
in fear of breaking things. And there were quite a number of issues reported 
wrt RTKit and PW+WP, last time I looked. IIUC that was one of the reasons for 
the (new) recommendation to using /etc/limits.conf and the pipewire group
- When I told/asked upstream how to use PW+WP in an unattended/headless 
manner, I got treated like I was insane and/or this was an insane use case. My 
primary use case was a 'soundserver' device connected to my AVR and one of the 
services it would run was mpd. In the end it was suggested that a systemd 
system service may be a way to get that to work (bug #1014927)
- Tuning the 'quantum' parameter seems to be considered a normal operation. 
Guess what. Not everyone is a (professional) sound engineer. I'm pretty sure 
95+% of Debian users have no idea what that is. I certainly don't. And I've 
spend quite a bit of time to figure out how to make PW+WP work and eventually 
just bailed out. I'm sure things have improved since, but at the beginning of 
the year I wasn't impressed.

I think there currently aren't that many Debian users which do use PW and I 
think that switching the default audio provider in all of Debian (not just 
Gnome) is FAR more involved then the impression I got from this ML thread.

I expect PW+WP to be the future and in several cases it is already superior 
then the alternatives. And I think a small minority of Debian users need that.

I think this is a switch that should be done at the beginning of the Trixie 
development cycle and then there is plenty of time to work out all the kinks 
which undoubtedly will surface when making the switch.
I thought ~ a year was tight, but 4 months is surely too short a timeframe.

My 0.02

signature.asc
Description: This is a digitally signed message part.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Dylan Aïssi]

Le jeu. 15 sept. 2022 à 03:21, Ben Hutchings  a écrit :
>
> I understand that applications with very low latency requirements may
> need this sort of performance tweaking.  But this is not the normal
> case, and PulseAudio hasn't required this.  If PipeWire does, I think
> that's a serious limitation in PipeWire, and it is not ready for us to
> make it the default.

Le jeu. 15 sept. 2022 à 05:35, Felipe Sateler  a écrit :
>
> This seems a step backwards to me. Even though pulseaudio also does the
> same, the code in question is from an era before rtkit existed. Nowadays,
> most users get their RT thread from rtkit. Why isn't rtkit enough for PW?

By default, pipewire uses rtkit (without removing its safeguards) and it
works perfectly without having choppy sound. In certain circumstances, we
need to do some performance tweaking. Now, we have to find the right
balance in the pipewire configuration to avoid playing with rtkit
safeguards.

I am not saying we should bypass rtkit (or remove its safeguards) by
default, or even recommend our users to do it. But, if they have a
particular use of pipewire requiring the upstream recommendations,
we can probably help them and explain them what are the risks.

Just a random example [1] where rtkit has limitation for some pipewire
uses. rtkit was enough for pulseaudio, but because pipewire goes beyond
pulseaudio support for real-time and low latency maybe that is no longer
sufficient? But again, we are not talking about a normal use of pipewire.


Dylan

[1] https://github.com/heftig/rtkit/issues/25

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Stone]

On Thu, Sep 15, 2022 at 06:13:35PM +0530, Nilesh Patra wrote:

As far as I can see, the latest "new upstream" upload to unstable was
in "2021-08-25" which is more than an year from now, post which there
have been few bug fix uploads.

More notable upload has been the one that enables gstreamer support
I'm not sure if this is what you are pointing towards with "hasn't stood still"


https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/

Ofcourse the maintainers of this package are doing an excellent job
but from upstream release pov, it is still kind of standing still.


So from the user perspective it's gained new functionality and also not 
broken what works. I can think of worse problems.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Nilesh Patra]

On Thu, Sep 15, 2022 at 08:22:52AM -0400, Michael Stone wrote:
> On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote:
> > Am 13.09.22 um 18:17 schrieb Antoine Beaupré:
> > > I also have the feeling that pipewire has already gone beyond what
> > > pulseaudio is capable of in terms of Bluetooth support, but I might be
> > > mistaken on that.
> > 
> > Interesting. What do you have in mind here? Supported codecs? AptX?
> > I had more success with PA in the past here, but that experience is
> > anecdotal.
> 
> PA also hasn't stood still,

As far as I can see, the latest "new upstream" upload to unstable was
in "2021-08-25" which is more than an year from now, post which there
have been few bug fix uploads.

More notable upload has been the one that enables gstreamer support
I'm not sure if this is what you are pointing towards with "hasn't stood still"


https://tracker.debian.org/news/1306307/accepted-pulseaudio-150dfsg1-4-source-into-unstable/

Ofcourse the maintainers of this package are doing an excellent job
but from upstream release pov, it is still kind of standing still.

(There's however a new release in experimental ATM)

> and PA+bluetooth is now working much better than
> it did even a few months ago.

This sounds a little vague. What does "much better" mean? What exactly changed 
(for you)?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Stone]

On Tue, Sep 13, 2022 at 07:25:12PM +0200, Michael Biebl wrote:

Am 13.09.22 um 18:17 schrieb Antoine Beaupré:

I also have the feeling that pipewire has already gone beyond what
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.


Interesting. What do you have in mind here? Supported codecs? AptX?
I had more success with PA in the past here, but that experience is 
anecdotal.


PA also hasn't stood still, and PA+bluetooth is now working much better 
than it did even a few months ago.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jeremy Bicha]

On Wed, Sep 14, 2022 at 11:36 PM Felipe Sateler  wrote:
> What does "switch right now" mean? Just switching gnome-core? What about
> the other users? They would all have to switch their order from
> `pulseaudio | pipewire-pulse` to `pipewire-pulse | pulseaudio`. Otherwise
> you would have a different audio server depending on which order packages
> are installed. Moreover, what about upgrades? Would they be forcefully
> upgraded (ie, drop the pulseaudio alternative)? Or would they be allowed
> to continue using pulseaudio (which wouldn't migrate them because the
> dependency would be satisfied)? This is what I mean with

Yes, I noticed the upgrade problem. apt recognizes that the alternate
dependency is already satisfied and doesn't install the preferred
(first) dependency.

So my draft was for gnome-core to unconditionally switch to pipewire:
https://salsa.debian.org/gnome-team/meta-gnome3/-/merge_requests/7/diffs

For context, gnome-core in Debian 11 "Bookworm" unconditionally
depends on pulseaudio.

> > This give us 4 months until the "transition and toolchain freeze" on
> > 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is
> > also doing the switch) planned to be released on 2022-10-20 [7].
>
> Do you know what the transition plan for ubuntu is? Are they patching all
> rdeps to switch to `pipewire-pulse`?

For Ubuntu Desktop, the ubuntu-desktop-minimal metapackage depends on
pipewire-pulse & wireplumber & recommends libspa-0.2-bluetooth.
Ubuntu's metapackages are generated using germinate and alternate
dependencies aren't supported at all.

https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/tree/desktop-minimal
(Recommends are the lines with parentheses).

In general, almost everything in Debian's GNOME metapackages are a
hard Depends instead of a Recommends. In our experience, we get a lot
of bugs and complaints about things not working correctly because
there are a lot of people who believe it's a good idea to disable
installing Recommends system-wide and have trouble understanding why
their system doesn't run well.

Interestingly, in Ubuntu, a lot of the ubuntu-desktop metapackage
dependencies are just Recommends. But even there, the sound server is
a hard dependency.

pipewire and wireplumber are systemd user services. Maybe we just need
to write up instructions for disabling PipeWire and switching to
PulseAudio. Or maybe we could create a Debian package that handles
this. That way we could keep the hard dependency in gnome-core so that
upgrades do the expected thing, but there is an easy escape.

However, I've not seen a single complaint from Ubuntu about switching
to PipeWire. So maybe we still ought to switch gnome-core now to get
real feedback.

Thank you,
Jeremy Bicha

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Felipe Sateler]

Hi!


On Wed, 14 Sep 2022 11:56:00 +0200, Dylan Aïssi wrote:

> Le mar. 13 sept. 2022 à 19:25, Michael Biebl  a écrit
> :
>>
>> Afaics, Dylan asked mostly if we should do the switch. He didn't give
>> any personal recommendation or preference. At least that's how I read
>> his initial email.
> 
> I have a basic usage of pipewire, I only listen to music and make video
> calls with friends/colleagues. That is why I am not representative and
> cannot force the switch (although I will be happy if it happens). Hence
> my suggestion to get feedback from you. (Thanks for all of your
> replies!)
> 
> We still have few packages depending/recommending/suggesting only on
> pulseaudio and not on either pulseaudio or pipewire-pulse [1]. I'll
> start tracking them and will propose a fix right now. This is even more
> important because the next pipewire-pulse package will be in conflict
> with the pulseaudio package to avoid fights between both servers [2] and
> because it is an upstream recommendation [3]. Currently, this is not a
> blocker since all the main packages already dep/rec/sug either
> pulseaudio or pipewire-pulse.

This would be true if we had a single place that said "install pulseaudio 
as a sound server". Unfortunately, we don't and that decision is scattered 
into lots of packages that have `pulseaudio | pipewire-pulse`.

> 
> The issue mentioned here regarding choppy audio in case of high CPU load
> and related rtkit errors messages, should be reduced with the next pkg
> version.
> As recommended by upstream [4], it will create a pipewire system group
> and set security limits [5]. The decision remains to users to add
> themselves in the pipewire group.

This seems a step backwards to me. Even though pulseaudio also does the 
same, the code in question is from an era before rtkit existed. Nowadays, 
most users get their RT thread from rtkit. Why isn't rtkit enough for PW?


> 
> Le mer. 14 sept. 2022 à 03:08, Felipe Sateler  a
> écrit :
>>
>> Dylan, have you thought about how a transition plan would look like?
> 
> Now, regarding the transition plan, I propose to switch right now to
> pipewire.

What does "switch right now" mean? Just switching gnome-core? What about 
the other users? They would all have to switch their order from 
`pulseaudio | pipewire-pulse` to `pipewire-pulse | pulseaudio`. Otherwise 
you would have a different audio server depending on which order packages 
are installed. Moreover, what about upgrades? Would they be forcefully 
upgraded (ie, drop the pulseaudio alternative)? Or would they be allowed 
to continue using pulseaudio (which wouldn't migrate them because the 
dependency would be satisfied)? This is what I mean with 

> This give us 4 months until the "transition and toolchain freeze" on
> 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is
> also doing the switch) planned to be released on 2022-10-20 [7]. 

Do you know what the transition plan for ubuntu is? Are they patching all 
rdeps to switch to `pipewire-pulse`?

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Ben Hutchings]

On Wed, 2022-09-14 at 11:56 +0200, Dylan Aïssi wrote:
[...]
> The issue mentioned here regarding choppy audio in case of high CPU load and
> related rtkit errors messages, should be reduced with the next pkg version.
> As recommended by upstream [4], it will create a pipewire system group and set
> security limits [5]. The decision remains to users to add themselves in the
> pipewire group.
[...]

This and the linked documentation makes me rather wary of PipeWire.

The purpose of RTKit is to allow limited use of real-time priority
without the risk of locking up the system if a real-time task starts
spinning.

What you are talking about with the pipewire group is bypassing RTKit
and allowing all processes started by certain users to use real-time
priority.  This does not seem like a good idea at all.

The alternative recommendation there seems to be, to reconfigure RTKit
to disable most of its safeguards.  (This might be wrong; I haven't dug
through the RTKit documentation.)

I understand that applications with very low latency requirements may
need this sort of performance tweaking.  But this is not the normal
case, and PulseAudio hasn't required this.  If PipeWire does, I think
that's a serious limitation in PipeWire, and it is not ready for us to
make it the default.

Ben.


-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


signature.asc
Description: This is a digitally signed message part

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Stephan Seitz]

Am Mi, Sep 14, 2022 at 08:41:32 -0400 schrieb Jeremy Bicha:

I believe you are significantly overstating the consequences of this
switch. It is just a dependency swap in meta-gnome3. The vast majority


Maybe, but I remember when pulseaudio was forced upon us, even when it 
was not really ready because other distributions made the switch and to 
get more testing.


Since PA ist now working very well (at least for me), I’m not interested 
in getting PipeWire as long as the upstream of PA is not dead.


Stephan

--
|If your life was a horse, you'd have to shoot it.|

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jeremy Bicha]

On Wed, Sep 14, 2022 at 8:07 AM Marvin Renich  wrote:
> A library transition that affects many rev-deps but is otherwise
> transparent to the end user is completely different from changing the
> audio stack where the end user will be required to learn a new set of
> tools and configuration files/syntax.

I believe you are significantly overstating the consequences of this
switch. It is just a dependency swap in meta-gnome3. The vast majority
of users will not have trouble configuring their audio. PipeWire
implements the PulseAudio API.

There is no basis to the idea that we must make all major changes to
Debian at the beginning of Debian's release cycle.

You're also compressing the timeline. Debian 12 will not be released 4
months from now. We have a transition freeze in January which we
understand to be the deadline for when we ought to have made a final
decision on this topic. We are still able to fix release critical bugs
until the Release and after the release as stable updates.

I think we should make the swap this week so we can see the actual
effects instead of hypothetical concerns.

Thank you,
Jeremy Bicha

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Marvin Renich]

* Dylan Aïssi  [220914 05:57]:
> Le mer. 14 sept. 2022 à 03:08, Felipe Sateler  a écrit :
> >
> > Dylan, have you thought about how a transition plan would look like?
> 
> Now, regarding the transition plan, I propose to switch right now to pipewire.
> This give us 4 months until the "transition and toolchain freeze" on
> 2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is also
> doing the switch) planned to be released on 2022-10-20 [7]. Thus, we will have
> 4 months for Debian and 2 months for Ubuntu to fix the worst bugs. Then, we

In my opinion, this is a major switch that should be started at the
beginning of a release cycle, not at the end (I completely agree with
Felipe).  Four months is not long enough to get appropriate testing.

You say there are four packages that depend on PA rather than PA | PW,
and the next version of PW will conflict with PA.  That means that
unless all four of those packages are fixed before the freeze, some
users will have trouble upgrading.  Four months is quite frequently an
inadequate amount of time to coordinate a change with upstream and get
that change back into Debian, and that doesn't even include testing by
users once that change gets into Debian.

Also, keep in mind that part of the transition will be users who need to
learn a new set of tools to get their audio working.  Those with more
complicated use cases, especially mission-critical ones, are going to
need to more time to make the switch, and it may not be convenient for
them to do so in the next four months.  It's not just about getting the
software in the release.

A library transition that affects many rev-deps but is otherwise
transparent to the end user is completely different from changing the
audio stack where the end user will be required to learn a new set of
tools and configuration files/syntax.

Please continue to coordinate the changes necessary to make the
transition, but hold off on the change until after the release.

...Marvin

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Dylan Aïssi]

Le mar. 13 sept. 2022 à 19:25, Michael Biebl  a écrit :
>
> Afaics, Dylan asked mostly if we should do the switch. He didn't give
> any personal recommendation or preference. At least that's how I read
> his initial email.

I have a basic usage of pipewire, I only listen to music and make video calls
with friends/colleagues. That is why I am not representative and cannot force
the switch (although I will be happy if it happens). Hence my suggestion to get
feedback from you. (Thanks for all of your replies!)

We still have few packages depending/recommending/suggesting only on
pulseaudio and not on either pulseaudio or pipewire-pulse [1]. I'll start
tracking them and will propose a fix right now. This is even more important
because the next pipewire-pulse package will be in conflict with the pulseaudio
package to avoid fights between both servers [2] and because it is an upstream
recommendation [3]. Currently, this is not a blocker since all the main
packages already dep/rec/sug either pulseaudio or pipewire-pulse.

The issue mentioned here regarding choppy audio in case of high CPU load and
related rtkit errors messages, should be reduced with the next pkg version.
As recommended by upstream [4], it will create a pipewire system group and set
security limits [5]. The decision remains to users to add themselves in the
pipewire group.

Le mer. 14 sept. 2022 à 03:08, Felipe Sateler  a écrit :
>
> Dylan, have you thought about how a transition plan would look like?

Now, regarding the transition plan, I propose to switch right now to pipewire.
This give us 4 months until the "transition and toolchain freeze" on
2023-01-12 [6]. We will also receive feedback from Ubuntu 22.10 (that is also
doing the switch) planned to be released on 2022-10-20 [7]. Thus, we will have
4 months for Debian and 2 months for Ubuntu to fix the worst bugs. Then, we
will re-evaluate the situation here from the first of January, this will give us
2 weeks before the freeze to switch back to pulseaudio if we have too many
unresolvable issues. Of course, this is not set in stone and we can still
switch back to pulseaudio before January if we find pipewire is not ready for
audio, but I am confident.

I will continue to propose latest pipewire/wireplumber versions in
bullseye-backports to get more feedback from users.


Dylan


[1] https://bugs.debian.org/992686
[2] https://bugs.debian.org/1013276
[3] 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#should-i-uninstall-everything-pulseaudio
[4] 
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Performance-tuning#rlimits
[5] https://bugs.debian.org/1011399
[6] https://release.debian.org/
[7] https://wiki.ubuntu.com/Releases

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Felipe Sateler]

Hi all,

Thanks for CCing me Michael, I would have missed this thread.

On Tue, Sep 13, 2022 at 2:25 PM Michael Biebl  wrote:

> Hi
>
> Am 13.09.22 um 18:17 schrieb Antoine Beaupré:
> > On Sat, 10 Sep 2022 12:17:23 +, Holger Levsen wrote:
> >> On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote:
> >>> Should we repeat this mistake? Or put this differently: is there a
> pressing
> >>> need/compelling reason to switch to pipewire in bookworm?
> >>> I.e. what I miss from the proposal are the benefits of pipewire over
> >>> pulseaudio.
> >>> Can you elaborate why you'd want to make the switch in bookworm?
>

I'm not sure you are being fair here. As your original message said, the
problem was mostly buggy drivers, which PA upstream refused to work around,
which forced the drivers to be fixed, which took time. In the long run a
beneficial status, but lots of pain in the short run.


> >>
> >> yes, I'm missing answers to these questions too.
> >
> > The most pressing reason to ship pipewire in bookworm is to have support
> > for scrensharing in Wayland, from what I understand. I am not very
> > familiar with that part, so I'll stop there, but that seems pretty huge
> > already.
>
> Yeah, I "think" you are mixing up video with audio here (but I might be
> wrong, if so apologies). We already had pipewire in bullseye for this
> very reason afair.
> The audio and video part are separate (to some extent).
> What Dylan is suggesting, is that we replace the audio part (i.e. PA
> with PW).
>
> If both audio and video is handled by PW, I guess some integration
> issues become simpler.
>
> > For me, the killer feature is that pipewire adds jack-like capabilities
> > to pulseaudio. This is really amazing: i've been able to use this to
> > help people debug their audio setups in videoconferencing by piping
> > their outputs into Ardour (or it could actually be any recorder!) and do
> > accoustic analysis there.
> >
> > That would have been *much* harder to do: possible, but hard.
> >
> > I also have the feeling that pipewire has already gone beyond what
> > pulseaudio is capable of in terms of Bluetooth support, but I might be
> > mistaken on that.
>
> Interesting. What do you have in mind here? Supported codecs? AptX?
> I had more success with PA in the past here, but that experience is
> anecdotal.
>

PA does handle AptX, LDAC and SBC XQ. Possibly PW got there first. PW does
have the handy feature of automatically switching profile when entering a
video call (to enable the mic) and then reverting back to A2DP when you
close that. I've installed PW locally for testing and the transition is
fairly smooth.


> >>> Personally, I'd rather see pipewire mature a little bit more before we
> make
> >>> the switch.
> >>
> >> same here.
> >
> > I think the timing is ripe. Ubuntu and Fedora switched already, so we
> > won't be the first guinea pigs. And if we *don't* switch now, it's going
> > to take *years* to shake off those bugs.
>
> Another release cycle, so 2 years more or less.
> What I tried to say here is that PA still to this day has a bad
> reputation and I think most of that is based on anecdotal experience.
>

Based on real bugs, experienced by real people, which took years to shake
off. I understand the allure of moving faster, but that should not mean we
intentionally hurt our users. Be kind to them!


> > And you *know* that people (like me) are going to try pipewire again
> > when bookworm comes out and then complain it "doesn't work in Debian",
> > and they will (rightly so, IMHO) blame Debian for not making it work
> > properly.
>

I don't understand this. PW does work fine in debian (at least in my
limited usage).


> >
> >>> This puts less pressure on you, as maintainer, and pipewire as upstream
> >>> project.
> >>
> >> yes.
> >
> > Well I guess I'd defer to the maintainer and upstream on that, but I
> > will point out that Pipewire maintainers *have* been careful about not
> > introducing pipewire as a default in *bullseye* in the past. If they
> > feel confident in doing so now, I would definitely trust their
> > judgement.
>
> Sure, completely agreed. I'd like to hear Dylan and Felipe's input here.
> So I've CCed Felipe as maintainer of PA, as I'm not sure if he's reading
> debian-devel.
> Afaics, Dylan asked mostly if we should do the switch. He didn't give
> any personal recommendation or preference. At least that's how I read
> his initial email.


> I'm subscribed to pkg-utopia's mailing list and therefor receive the bug
> mail related to PW. Dylan is doing an excellent job in handling those.
> My gut feeling is though, that there might still be a few rough edges
> and integration issues that PA had years to deal with.
>
> If Dylan feels confident to deal with those and Felipe acks the switch,
> then I trust them fully. They certainly know more about this stuff then
> I do.
>

>From my end, my only doubt would be about the timing. Freeze is in 4
months, so that is a limited time to shake out 

Re: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Holger Levsen]

Thanks Antoine and Dylan for those two mails today, now I have a much better
understanding of the reasons for switching!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Everyone is entitled to their own opinion, but not their own facts.


signature.asc
Description: PGP signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Biebl]

Hi

Am 13.09.22 um 18:17 schrieb Antoine Beaupré:

On Sat, 10 Sep 2022 12:17:23 +, Holger Levsen wrote:

On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote:

Should we repeat this mistake? Or put this differently: is there a pressing
need/compelling reason to switch to pipewire in bookworm?
I.e. what I miss from the proposal are the benefits of pipewire over
pulseaudio.
Can you elaborate why you'd want to make the switch in bookworm?


yes, I'm missing answers to these questions too.


The most pressing reason to ship pipewire in bookworm is to have support
for scrensharing in Wayland, from what I understand. I am not very
familiar with that part, so I'll stop there, but that seems pretty huge
already.


Yeah, I "think" you are mixing up video with audio here (but I might be 
wrong, if so apologies). We already had pipewire in bullseye for this 
very reason afair.

The audio and video part are separate (to some extent).
What Dylan is suggesting, is that we replace the audio part (i.e. PA 
with PW).


If both audio and video is handled by PW, I guess some integration 
issues become simpler.



For me, the killer feature is that pipewire adds jack-like capabilities
to pulseaudio. This is really amazing: i've been able to use this to
help people debug their audio setups in videoconferencing by piping
their outputs into Ardour (or it could actually be any recorder!) and do
accoustic analysis there.

That would have been *much* harder to do: possible, but hard.

I also have the feeling that pipewire has already gone beyond what
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.


Interesting. What do you have in mind here? Supported codecs? AptX?
I had more success with PA in the past here, but that experience is 
anecdotal.



Personally, I'd rather see pipewire mature a little bit more before we make
the switch.


same here.


I think the timing is ripe. Ubuntu and Fedora switched already, so we
won't be the first guinea pigs. And if we *don't* switch now, it's going
to take *years* to shake off those bugs.


Another release cycle, so 2 years more or less.
What I tried to say here is that PA still to this day has a bad 
reputation and I think most of that is based on anecdotal experience.



And you *know* that people (like me) are going to try pipewire again
when bookworm comes out and then complain it "doesn't work in Debian",
and they will (rightly so, IMHO) blame Debian for not making it work
properly.


This puts less pressure on you, as maintainer, and pipewire as upstream
project.


yes.


Well I guess I'd defer to the maintainer and upstream on that, but I
will point out that Pipewire maintainers *have* been careful about not
introducing pipewire as a default in *bullseye* in the past. If they
feel confident in doing so now, I would definitely trust their
judgement.


Sure, completely agreed. I'd like to hear Dylan and Felipe's input here. 
So I've CCed Felipe as maintainer of PA, as I'm not sure if he's reading 
debian-devel.
Afaics, Dylan asked mostly if we should do the switch. He didn't give 
any personal recommendation or preference. At least that's how I read 
his initial email.


I'm subscribed to pkg-utopia's mailing list and therefor receive the bug 
mail related to PW. Dylan is doing an excellent job in handling those.
My gut feeling is though, that there might still be a few rough edges 
and integration issues that PA had years to deal with.


If Dylan feels confident to deal with those and Felipe acks the switch, 
then I trust them fully. They certainly know more about this stuff then 
I do.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Re: Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Antoine Beaupré]

On Sat, 10 Sep 2022 12:17:23 +, Holger Levsen wrote:
> On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote:
> > Should we repeat this mistake? Or put this differently: is there a pressing
> > need/compelling reason to switch to pipewire in bookworm?
> > I.e. what I miss from the proposal are the benefits of pipewire over
> > pulseaudio.
> > Can you elaborate why you'd want to make the switch in bookworm?
> 
> yes, I'm missing answers to these questions too.

The most pressing reason to ship pipewire in bookworm is to have support
for scrensharing in Wayland, from what I understand. I am not very
familiar with that part, so I'll stop there, but that seems pretty huge
already.

For me, the killer feature is that pipewire adds jack-like capabilities
to pulseaudio. This is really amazing: i've been able to use this to
help people debug their audio setups in videoconferencing by piping
their outputs into Ardour (or it could actually be any recorder!) and do
accoustic analysis there.

That would have been *much* harder to do: possible, but hard.

I also have the feeling that pipewire has already gone beyond what
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.

> > Personally, I'd rather see pipewire mature a little bit more before we make
> > the switch.
> 
> same here.

I think the timing is ripe. Ubuntu and Fedora switched already, so we
won't be the first guinea pigs. And if we *don't* switch now, it's going
to take *years* to shake off those bugs.

And you *know* that people (like me) are going to try pipewire again
when bookworm comes out and then complain it "doesn't work in Debian",
and they will (rightly so, IMHO) blame Debian for not making it work
properly.

> > This puts less pressure on you, as maintainer, and pipewire as upstream
> > project.
> 
> yes.

Well I guess I'd defer to the maintainer and upstream on that, but I
will point out that Pipewire maintainers *have* been careful about not
introducing pipewire as a default in *bullseye* in the past. If they
feel confident in doing so now, I would definitely trust their
judgement.

As for upstream, this is their response to this FAQ:

https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ#is-pipewire-ready-yet

Excerpt:

| Is PipeWire Ready Yet?
|
| It is pretty much ready for most users. It has been used since Fedora
| 27 (November 2017) for Wayland screen sharing and has been the default
| audio server since Fedora 34 (April 2021).
|
| The API/ABI has been declared stable since version 0.3.
|
| The protocol can support older 0.2 version clients transparently. This
| means that flatpaks with older PipeWire libraries can connect to a
| newer daemon.

I mean yeah, it's 0.3, but they have a stable API and they say it's
"pretty much ready for most users". I wouldn't even put Pulseaudio in
this category, because *many* users can't use it for their main task
(e.g. all pro audio users will need jack or pipewire instead).

So, you know, I think it might just be ready! :)

My personal, completely anecdotal experience with this is that I had
some issues running it in *bullseye*. I filed a bug report about ardour
interoperability (#994208) and that is probably already fixed. I just
need to test this in bookworm, which is why I'm interested in this
discussion in the first place.

Also note that enabling pipewire was kind of clunky in bullseye. I don't
know if that improved since then, but that makes it so most users won't
actually try it until it's made default. So there's an argument to be
made here that we should switch the default, even if temporarily -- say
in unstable for a while -- just to get our unstable users to try it out
more, so we can get a feedback loop going there.

The freeze is coming, we should do this now, and not in a year.

a.
a.
-- 
Premature optimization is the root of all evil
- Donald Knuth

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Dylan Aïssi]

Le ven. 9 sept. 2022 à 21:39, Michael Biebl  a écrit :
>
> Should we repeat this mistake? Or put this differently: is there a
> pressing need/compelling reason to switch to pipewire in bookworm?
> I.e. what I miss from the proposal are the benefits of pipewire over
> pulseaudio.
> Can you elaborate why you'd want to make the switch in bookworm?

Le lun. 12 sept. 2022 à 20:30, Jeremy Bicha
 a écrit :
>
> A brief explanation of the project and what it does can be found at
> https://pipewire.org/ and more details are at
> https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ

These links and especially the second one reply to the questions what are the
benefits of pipewire and why we should switch to pipewire.

To summarize, pipewire is able to deal with a lower latency and with less CPU
usage than pulseaudio. This improves video conferencing apps, like WebRTC in
the browser. A very common practice these days. Using less CPU ressources is
also something we should be careful even if in this case it is marginal.

Pipewire improves the security by stopping applications from snooping on each
other's audio. It also asks permission to Wayland or Flatpak to record
audio (and video).

PipeWire allows a finer control of applications are linked to devices and
filters. Take a look at qpwgraph or helvum (the latter is not yet in Debian).

PipeWire does not dictate policy management. It exposes nodes to be connected,
but leaves the decisions on the connections to the policy manager.
Currently, we have two policy managers in Debian: pipewire-media-session and
wireplumber.

Best,
Dylan

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jeremy Bicha]

On Thu, Sep 8, 2022 at 11:59 AM Dylan Aïssi  wrote:
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.

I think it's a good idea to switch the Debian GNOME default sound
service to PipeWire now. I've just been waiting for wireplumber
0.4.11-4 to make it through the NEW queue since it fixes a minor
packaging issue.

A brief explanation of the project and what it does can be found at
https://pipewire.org/ and more details are at
https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/FAQ

>From what I've seen, PipeWire will be as good as or better than
PulseAudio for most users. By switching now, we should get enough
feedback from both Debian Testing and Ubuntu 22.10 to fix serious bugs
or perhaps revert to PulseAudio if necessary before we freeze too much
for Debian 12.

Most but not all of the Ubuntu desktop flavors have also switched to
PipeWire for Ubuntu 22.10. I'm not involved in the decisions for other
Debian desktop flavors but they would get the same advantages and
their apps designed for PulseAudio should still work with PipeWire.

Thank you,
Jeremy Bicha

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Holger Levsen]

On Fri, Sep 09, 2022 at 09:38:39PM +0200, Michael Biebl wrote:
> Should we repeat this mistake? Or put this differently: is there a pressing
> need/compelling reason to switch to pipewire in bookworm?
> I.e. what I miss from the proposal are the benefits of pipewire over
> pulseaudio.
> Can you elaborate why you'd want to make the switch in bookworm?

yes, I'm missing answers to these questions too.
 
> Personally, I'd rather see pipewire mature a little bit more before we make
> the switch.

same here.

> This puts less pressure on you, as maintainer, and pipewire as upstream
> project.

yes.


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Money is worth nothing on a dead planet.


signature.asc
Description: PGP signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Paul Wise]

On Fri, 2022-09-09 at 15:06 +0200, Vincent Bernat wrote:

> I also had this issue. This was greatly improved since May and I am
> now using it instead of PulseAudio. Check that you have rtkit-daemon 
> installed. It helps.

I have rtkit installed, running and working for my UID according to the
logs, but pipewire/pipewire-pulse/wireplumber all get a denied message:

   mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
   mod.rt: could not make thread 3367 realtime using RTKit: Permission denied

The upstream issue for this problem seems to be this:

   https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1069

Some folks solved it by editing the rtkit policy in polkit, others by
updating security limits, others by disabling systemd logind lingering.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Michael Biebl]

Am 08.09.22 um 17:58 schrieb Dylan Aïssi:

Hi,

I have been asked several times regarding when Debian will switch its default
sound server from PulseAudio to PipeWire without having an official answer.
Thus, I suppose it's the right time to start a discussion about that.


I really like the idea of pipewire and have installed it on my personal 
laptop to get a better view of it. It works fine for the most part with 
some minor issues now and then (like applications not noticing when I 
switch the input/output) which I haven't noticed with PulseAudio.


PulseAudio had a rather rough start: to some extent this is not by its 
own fault, since drivers / ALSA were simply more buggy at that time. To 
some extent it was a result of the introduction of PulseAudio being rushed.


Should we repeat this mistake? Or put this differently: is there a 
pressing need/compelling reason to switch to pipewire in bookworm?
I.e. what I miss from the proposal are the benefits of pipewire over 
pulseaudio.

Can you elaborate why you'd want to make the switch in bookworm?


Personally, I'd rather see pipewire mature a little bit more before we 
make the switch.
This puts less pressure on you, as maintainer, and pipewire as upstream 
project.


Regards,
Michael










OpenPGP_signature
Description: OpenPGP digital signature

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Jérémy Lal]

Le ven. 9 sept. 2022 à 15:06, Vincent Bernat  a écrit :

> On 2022-09-09 04:51, Paul Wise wrote:
> > On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote:
> >
> >> I have been asked several times regarding when Debian will switch its
> default
> >> sound server from PulseAudio to PipeWire without having an official
> answer.
> >> Thus, I suppose it's the right time to start a discussion about that.
> >
> > I switched to PipeWire some time ago. I don't have particularly complex
> > audio needs (just AUX/headphones on a desktop). When the system is
> > under load and the CPU throttled, I get choppy audio, which is
> > especially annoying when the load is caused by a video. That doesn't
> > happen with PulseAudio and setting the quantum to 2048 is a workaround.
> >
> > pw-metadata -n settings 0 clock.force-quantum 2048
> >
> > Probably there are more of these sorts of issues, so I agree we should
> > switch to it by default sooner rather than later to find the problems.
>
> I also had this issue. This was greatly improved since May and I am now
> using it instead of PulseAudio. Check that you have rtkit-daemon
> installed. It helps.


wireplumber (up-to-date sid) on an armhf laptop:
- same problem as above (even with rtkit + force-quantum) which wasn't the
case with pulseaudio
- micro no longer recognized
- hdmi audio jack no longer recognized
- headphones have no sound
This laptop have a rockchip alsa ucm2 profile, alsa sees speakers, micro,
headphones, hdmi,
but not pipewire apparently.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Vincent Bernat]

On 2022-09-09 04:51, Paul Wise wrote:

On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote:


I have been asked several times regarding when Debian will switch its default
sound server from PulseAudio to PipeWire without having an official answer.
Thus, I suppose it's the right time to start a discussion about that.


I switched to PipeWire some time ago. I don't have particularly complex
audio needs (just AUX/headphones on a desktop). When the system is
under load and the CPU throttled, I get choppy audio, which is
especially annoying when the load is caused by a video. That doesn't
happen with PulseAudio and setting the quantum to 2048 is a workaround.

pw-metadata -n settings 0 clock.force-quantum 2048

Probably there are more of these sorts of issues, so I agree we should
switch to it by default sooner rather than later to find the problems.


I also had this issue. This was greatly improved since May and I am now 
using it instead of PulseAudio. Check that you have rtkit-daemon 
installed. It helps.

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Paul Wise]

On Thu, 2022-09-08 at 17:58 +0200, Dylan Aïssi wrote:

> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.

I switched to PipeWire some time ago. I don't have particularly complex
audio needs (just AUX/headphones on a desktop). When the system is
under load and the CPU throttled, I get choppy audio, which is
especially annoying when the load is caused by a video. That doesn't
happen with PulseAudio and setting the quantum to 2048 is a workaround.

   pw-metadata -n settings 0 clock.force-quantum 2048 

Probably there are more of these sorts of issues, so I agree we should
switch to it by default sooner rather than later to find the problems.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Adam Borowski]

On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Aïssi wrote:
> I have been asked several times regarding when Debian will switch its default
> sound server from PulseAudio to PipeWire without having an official answer.
> Thus, I suppose it's the right time to start a discussion about that.

If we're going to default to PipeWire in Bookworm, please switch NOW.
Our custom is to make all the big changes the day before freeze, ending up
with untested and buggy stuff.

> for screen-sharing.  PipeWire was not mature enough to use it as default
> sound server for Bullseye, but since it gained stability

PulseAudio is notorious for failing to work on _some_ machines or working
badly (eg. http://angband.pl/tmp/clem/pulse.flac), so even in the worst case
we trade one set of bugs for another.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Switch default from PulseAudio to PipeWire (and WirePlumber) for audio

[Dylan Aïssi]

Hi,

I have been asked several times regarding when Debian will switch its default
sound server from PulseAudio to PipeWire without having an official answer.
Thus, I suppose it's the right time to start a discussion about that.

As you know, PipeWire is already installed by default with Bullseye (at least
with Wayland environments) for screen-sharing. PipeWire was not mature enough
to use it as default sound server for Bullseye, but since it gained in
stability, features and popularity. Several other major distributions
(Fedora, Ubuntu is doing the switch with 22.10) have switched to PipeWire
for audio [1-3].

We cannot talk about PipeWire without mentioning its session manager.
Thus, this change should go along the switch of the default session manager,
i.e. from the deprecated pipewire-media-session to WirePlumber.
We still use pipewire-media-session as default session manager because it
enables PipeWire *only* for screen-sharing and not for managing audio.
Whereas WirePlumber always configures PipeWire for audio excepted by modifying
conf files in a non-compatible packaging way. This issues was also hit on
the Arch Linux side [4]. This WirePlumber behavior may be solved in the next
major release 0.5 planned later this year.

BTW, I just uploaded latest PipeWire and WirePlumber in bullseyes-backports
(still in the NEW queue) to allow more users to test them.

Best,
Dylan

[1] https://fedoraproject.org/wiki/Changes/DefaultPipeWire
[2] https://fedoraproject.org/wiki/Changes/WirePlumber
[3] https://wiki.ubuntu.com/ImpishIndri/ReleaseNotes
[4] 
https://archlinux.org/news/undone-replacement-of-pipewire-media-session-with-wireplumber/