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.
for screen-sharing. PipeWire was not mature enough to use it as default sound server for Bullseye, but since it gained stability
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.
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.
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.
<div>- hdmi audio jack no longer recognized</div><div>- headphones have no sound</div><div>This laptop have a rockchip alsa ucm2 profile, alsa sees speakers, micro, headphones, hdmi,</div><div>but not pipewire apparently.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div>
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.
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.
I have been asked several times regarding when Debian will switch its default sound server from PulseAudio to PipeWire without having an official answer.
From what I've seen, PipeWire will be as good as or better thanPulseAudio for most users. By switching now, we should get enough
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?
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
Hi
Am 13.09.22 um 18:17 schrieb Antoine Beaupré:
On Sat, 10 Sep 2022 12:17:23 +0000, 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.
From my end, my only doubt would be about the timing. Freeze is in 4months, so that is a limited time to shake out bugs. I also have no idea
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.
Dylan, have you thought about how a transition plan would look like?
Le mer. 14 sept. 2022 03:08, Felipe Sateler <fsateler@debian.org> 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
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
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 mar. 13 sept. 2022 à 19:25, Michael Biebl <biebl@debian.org> 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 <fsateler@debian.org> 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].
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`?
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.
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.
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.
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.
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?
On 10 Nov 2021 15:40:21 +0100 Sebastien Bacher <seb128@ubuntu.com> 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.
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).
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.
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.
"Dylan" == Dylan Aïssi <daissi@debian.org> writes:
Hi,
On Tue, 13 Sept 2022 at 13:39, Antoine Beaupré <anarcat@orangeseeds.org> wrote:
[snip]
I also have the feeling that pipewire has already gone beyond whatWell, with pulseaudio I always needed to run the following each time I
pulseaudio is capable of in terms of Bluetooth support, but I might be
mistaken on that.
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 :-/
* If you do need jackd for real because pipewire's jack isn't quite goodFWIW, I did manage to get a jack client in pipewire by setting
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.
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).
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.
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.
* Finally, I can use bluetooth on linux with reasonably good audio
quality!
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.
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.
[1] I already have alsa, jack, pulseaudio, pipewire packages
installed... At least no oss anymore! :)
On Thu, Sep 08, 2022 at 05:58:25PM +0200, Dylan Assi 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.
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.
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.
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/
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 ;-)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 152:27:23 |
| Calls: | 10,383 |
| Files: | 14,054 |
| Messages: | 6,417,816 |