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.
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)