[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hi all,

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

On Tue, Sep 13, 2022 at 2:25 PM Michael Biebl <biebl@debian.org> wrote:
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?

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 bugs. I also have no idea how that transition would look like, since I have not given any thought to it. Pulseaudio has lots of reverse dependencies, so possibly some virtual packaging shenanigans will be needed, and we know from experience they tend to show some weird edge-cases. 
That said, I would very much welcome that transition when it comes. PW does seem a lot more active than PA[1][2]. Moreover, a long-lasting maintainer has stepped down from PA recently[3], leaving only two maintainers. PW does address some design issues in PA, such as security (although I find it sad that they decided to implement per-user daemons instead of a global one. that means the many bugs about conflict with speech-dispatcher will persist). And finally, that would be less work for me :)

Dylan, have you thought about how a transition plan would look like?


[1] https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/graphs/master
[2] https://gitlab.freedesktop.org/pipewire/pipewire/-/graphs/master
[3] https://lists.freedesktop.org/archives/pulseaudio-discuss/2022-August/032320.html
 

--

Saludos,
Felipe Sateler

Reply to: