PipeWire: The Linux audio/video bus [LWN.net]

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 10:59 UTC (Wed) by smcv (subscriber, #53363)
Parent article: PipeWire: The Linux audio/video bus

> Debian offers PipeWire packages, but replacing PulseAudio or JACK is "an unsupported use case."

The ability to use PipeWire to replace the other audio services didn't arrive at a great time for the Debian 11 release cycle - in the versions that were available at freeze time, it can be made to work, but didn't seem mature enough to support for 2 years with minimal changes. The packaging is set up to make it possible, but making it straightforward without introducing regressions will need help from domain experts.

The maintainer-of-record for Debian's PipeWire packaging has been busy with other things, so the 0.2 -> 0.3 transition had to be done by other contributors (such as me) in order to keep screen sharing and screencasting working in GNOME, and I wouldn't feel comfortable pushing forward a transition to PipeWire for audio on its current level of maintainer bandwidth.

I suspect PipeWire for audio might become the recommendation in the Debian 12 cycle if more knowledgeable maintainers step in.

to post comments

PipeWire: The Linux audio/video bus

Posted Mar 3, 2021 21:19 UTC (Wed) by paravoid (subscriber, #32869) [Link] (3 responses)

Thank you so much for all of the efforts here :) The timing is indeed unfortunate! It's kind of a pity that we're missing all the 0.3.{20,21,22} improvements though (AIUI Fedora will release with .22). Perhaps it would be worth asking the Debian release team for a freeze exception for 0.3.22 here so that users could at least have the same level of experience as Fedora 34 users by opting in?

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 4:48 UTC (Thu) by simcop2387 (subscriber, #101710) [Link]

This is likely to happen not as a freeze exception but instead as a backport from testing once the release happens. That leaves the known working config in stable and then testing and backports can deal with any lingering issues. It's one reason why I either run testing or backports on my systems (depending on the level of pain I'm willing to deal with at the time).

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 13:44 UTC (Thu) by smcv (subscriber, #53363) [Link] (1 responses)

If you think you can justify each line of diff to the release team, go for it (I'd suggest talking to Sjoerd, who uploaded 0.3.22 to experimental). Or, if there are individual commits that have a low regression risk and high importance, please go ahead.

However, *I* don't understand the pipewire code well enough to be the one justifying to the release team why we need any particular change, and it still seems to be at the stage of maturity where targeted bug fixes, higher-regression-risk feature work, and harder-to-review refactoring/restructuring are mixed into one stream of commits; so I don't feel comfortable treating it like I would treat a bugfix-only stable-branch, like (say) GNOME Shell 3.38.x.

Sorry, I've done what I can, and if other people can do a better job then I'll be happy to step out of the way, but I am not the person to make this happen myself.

PipeWire: The Linux audio/video bus

Posted Mar 4, 2021 17:29 UTC (Thu) by darwi (subscriber, #131202) [Link]

> However, *I* don't understand the pipewire code well enough to be the one justifying to the release team why we need any particular change

The PipeWire commit logs are also very terse, and a lot of times just one-liners with no further context. IMHO, the project should really improve its commit logs from now on, especially that distributions are beginning to adopt it by default.

In fairness, the source code was a real beauty to look at; but the commit logs… not so much.

PipeWire: The Linux audio/video bus

Posted Mar 8, 2021 6:43 UTC (Mon) by joib (subscriber, #8541) [Link] (1 responses)

> I suspect PipeWire for audio might become the recommendation in the Debian 12 cycle if more knowledgeable maintainers step in.

Thanks for the heads-up, and for your work in this. Hope things get sorted out for Debian 12 and the next Ubuntu LTS (22.04?).

And getting a bit off-topic, this seems to be another example where the Debian "culture" (or what should it be called?) of packages by default being single-maintainer fiefdoms is hurtful to the project and users. Hopefully this can eventually be fixed as well (though I'm not holding my breath).

PipeWire: The Linux audio/video bus

Posted Mar 9, 2021 18:29 UTC (Tue) by emorrp1 (guest, #99512) [Link]

Well it is part of the Utopia team, otherwise smcv would have had to go via NMUs, but that does seem to be a very loose collection of desktop software. Some teams do make deliberate effort to upload each others packages (IIRC started by debian-med advertising team graphs), others contribute but tend to let the primary uploader do their thing.

This graph shows pretty clearly that the fiefdom culture is now largely an historical artifact, but ultimately everything relies on volunteers, and therefore interest/buy-in from someone other than the initial uploader.