On Fri, 20 Nov 2020 at 17:28, Ben Cotton <bcotton@redhat.com> wrote:
https://fedoraproject.org/wiki/Changes/DefaultPipeWire

== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.

== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans@gmail.com


== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.

The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.

This proposal is to replace the PulseAudio daemon with a functionally
compatible implementation
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.

All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.

For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.

With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.

== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.

== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.

Some of the benefits that PipeWire will bring:

 * PRO Audio features

   PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
   the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
   the system (and PulseAudio in particular).

   With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
   integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
   closer to the experience of other operating systems.

 * Flexibility/Integration

   PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
   and the management into separate processes. This makes it possible
to better integrate with
   the other system components or swap out the default policy for a
highly customized one (such as
   for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
   into the daemon with limited configuration options.

   In the next phase we expect to greatly expand the user experience
and configuration of the
   audio infrastructure with better integration throughout the system.

 * Performance

   PipeWire was designed for high performance and low-latency, using
much of the same design as
   JACK. JACK application should run with comparable performance even
in low-latency situations.

 * Security

   PipeWire enforces per client security. Object visibility and the
actions on them can be
   configured independently per client. This makes it possible to
enforce a security policy for
   sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
   block them from interfering with other applications.

 * Maintainability

   Both PulseAudio and JACK have very slow development cycles with few
new features. The more
   flexible and distributed nature of the design of PipeWire should
encourage more new features
   and use-cases.

== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.

The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.

We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.

The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.

* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.

pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34

 * avahi network discovery and audio routing. This is not enabled by
default but can be activated
   with paprefs. this includes TCP and RTP transport of audio.
 * make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
 * easy configuration of combining all sinks. Questionable feature but
possible via paprefs.

User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
anymore.

Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:

 * latency reporting: useful to align streams
 * freewheeling: used when rendering a project
 * jackdbus: used by some tools to manage the graph


== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.

To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).

To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.

After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.

Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:

 - patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
 - gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
                         switch.
 - pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
 - firefox: check out a website with audio/video such as youtube and
verify that audio works as
            usual. Check out a website with a video chat test page
(bluejeans.com/111).
 - rhythmbox: check if playback works as expected
 - bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
 - Regular system usage and performance should not change.
 - JACK tools such as catia, carla should run and can be used to
inspect the graph.


== User Experience ==
In general, users should not be able to see any change when using
PulseAudio applications.

The big change is when using JACK application:

 - They will start without having to configure and start the daemon.
this includes
   the period size and sample rates.
 - All devices will be visible in the graph with meaningful names. Devices will
   be automatically slaved when needed without needing any configuration.
 - bluetooth devices will be usable as well.

== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.

== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No


== Documentation ==
[https://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md](install
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md](how
to use/test)

--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

> For legacy ALSA clients, we will install an ALSA plugin that routes
> the audio directly to
> PipeWire. 

Is ALSA still a valid use case? I thought ALSA support was phased out from most relevant software?

I'd say "no" to replacing pulseaudio daemon, but "yes" to giving it more polish and perhaps aiming for Fedora 35?
PulseAudio itself is stable, but still breaks in edge cases (old games, WINE) so I'd give PipeWire more time.