[Pkg-utopia-maintainers] Bug#994165: pipewire: add pipewire-alsa/pipewire-jack packages

[Simon McVittie]

On Mon, 13 Sep 2021 at 10:45:59 +0800, Paul Wise wrote:
> On Arch Linux, to enable forwarding of the ALSA and JACK APIs to
> PipeWire you only have to install pipewire-alsa and pipewire-jack while
> on Debian you have to manually copy some files around. I think it would
> be better to follow the Arch Linux model and have -alsa/-jack packages
> just like there is the pipewire-pulse package in Debian.

On Mon, 13 Sep 2021 at 20:01:33 +0200, Patrice Duroux wrote:
> I suppose that you have already got a look to pipewire-audio-client-libraries
> that gives your expectation. May be you just propose to split it into 2
> separated packages?
> Also the long description of pipewire-audio-client-libraries mentions PulseAudio
> which is already entirely took-apart into pipewire-pulse.

For context, when I added pipewire-audio-client-libraries shortly before
the bullseye freeze, using pipewire for audio was considered very
experimental; all I was trying to do with it was to enable people to
experiment without needing additional trips through NEW.

pipewire-pulse is a new thing since then, and is now the 90% solution to
getting audio via pipewire.

Pipewire's audio support in general has improved a lot since
bullseye, and I agree that it could make sense to restructure
pipewire-audio-client-libraries to be less like an experiment and more
production-ready.

For JACK, I think the way forward might be a libjack0-pipewire or pipewire-jack
package that puts Pipewire's JACK implementation into the default linker path
(instead of an experimental off-path location like
pipewire-audio-client-libraries currently does), has the same Provides
that libjack-jackd2-0 and libjack0 do, and either has the same Conflicts
they do, diverts them out of the way with dpkg-divert, or installs to
/usr/lib/x86_64-linux-gnu/pipewire-0.3/jack and uses
/etc/ld.so.conf.d/pipewire-jack-x86_64-linux-gnu.conf to make that
directory higher-precedence than "real" JACK.
This would mean that users of, for example, mixxx could install
libjack0-pipewire instead of libjack-jackd2-0.

Similarly, for the ALSA client library libasound.so.2, now that using
pipewire for audio is more normal, a libasound2-pipewire or pipewire-alsa
package that installs 99-pipewire-default.conf (not just as an example
this time) might be a better fit.

Both should probably have a Recommends or Depends on pipewire-pulse,
because if you want JACK clients' audio to come out via Pipewire, the
same is almost certainly true for PulseAudio clients.

So, maybe something like this:

libjack0-pipewire (Multi-Arch: same):
/usr/bin/pw-jack (has little or no practical effect)
/usr/lib/${DEB_HOST_MULTIARCH}/libjack.so.0
/usr/lib/${DEB_HOST_MULTIARCH}/libjack.so.0.*
/usr/lib/${DEB_HOST_MULTIARCH}/libjacknet.so.0
/usr/lib/${DEB_HOST_MULTIARCH}/libjacknet.so.0.*
/usr/lib/${DEB_HOST_MULTIARCH}/libjackserver.so.0
/usr/lib/${DEB_HOST_MULTIARCH}/libjackserver.so.0.*

libasound2-pipewire (Multi-Arch: same):
/etc/alsa/conf.d/50-pipewire.conf
/etc/alsa.conf.d/99-pipewire-default.conf
/usr/lib/${DEB_HOST_MULTIARCH}/alsa-lib/libasound_module_ctl_pipewire.so
/usr/lib/${DEB_HOST_MULTIARCH}/alsa-lib/libasound_module_pcm_pipewire.so

Or they could both stay in one big pipewire-audio-client-libraries package
- but probably only if that isn't going to interfere with installing
JACK -dev packages for build-dependencies.

JACK maintainers: do the structures I've mentioned sound correct?

Thanks,
    smcv