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