After doing some tests today using pipewire as default on Fedora 33, I got this issue: #1907617. 
In summary, with pipewire, the media keys don't work properly with Mate Desktop. It sounds to me that there's a race condition with input switch events at mate-notification-daemon.

(In reply to Mauro Carvalho Chehab from comment #1)
> After doing some tests today using pipewire as default on Fedora 33, I got
> this issue: #1907617. 
> In summary, with pipewire, the media keys don't work properly with Mate
> Desktop. It sounds to me that there's a race condition with input switch
> events at mate-notification-daemon.

RH issue: https://bugzilla.redhat.com/show_bug.cgi?id=1907617
Upstream one: https://github.com/mate-desktop/mate-settings-daemon/issues/343

My Bose QC35's connected via bluetooth stop working after upgrading to Pipewire. I'll investigate more.

Reminder: The change complete (100% complete) deadline for Fedora 34 changes is Tuesday 23 February. At that point, changes should be 100% code complete, along with supporting documentation where appropriate. Please indicate this by setting the tracker bug for your change to ON_QA.

Generally the switch to pipewire for audio has been fine, however I am finding media files with multichannel audio result in static. Stereo files are fine but 3f2r/lfe channel configs (Three Front, Two Rear plus Low Frequency ie 5.1 surround) play back as static. Reverting to pulseaudio they playback fine.

I tried moving my Fedora 33 to pipewire. I noticed many problems: chromium youtube video stopping, bluetooth speakers no more working. But the most annoying problem is: apparently I'm no more able to go back to pulseaudio. 

When starting the computer again after the "dnf swap" command, both pulseaudio and pipewire daemons were started, and the gnome settings audio page acts weird: selecting a different output the audio is still routed to the previous one. Even with pipewire stopped (with systemctl mask command, disable was not enough).

Is a per-user problem, not system-wide, as a new user has no problem.

(In reply to Gabriele Turchi from comment #6)
> I tried moving my Fedora 33 to pipewire. I noticed many problems: chromium
> youtube video stopping, bluetooth speakers no more working. But the most
> annoying problem is: apparently I'm no more able to go back to pulseaudio. 
> 
> When starting the computer again after the "dnf swap" command, both
> pulseaudio and pipewire daemons were started, and the gnome settings audio
> page acts weird: selecting a different output the audio is still routed to
> the previous one. Even with pipewire stopped (with systemctl mask command,
> disable was not enough).
> 
> Is a per-user problem, not system-wide, as a new user has no problem.

Some little update: apparently chromium-freeworld needs an older version of the pipewire libraries, and is not fully compatible with a full pipewire installation. But it needs a pipewire daemon running, so my problem was not the pipewire daemon running, but just the opposite.

Please, in case pipewire will become the default in Fedora 34, please consider at least basic functionality for chromium-freeworld.

Using pipewire-pulse breaks audio output on Skype for Linux and Microsoft Teams, sound input works fine. Switching back to PulseAudio works but I don't consider that a valid solution. Both do offer a web-based version that does work, although with limited functionality.

(In reply to Gregor Schram from comment #8)
> Using pipewire-pulse breaks audio output on Skype for Linux and Microsoft
> Teams, sound input works fine. Switching back to PulseAudio works but I
> don't consider that a valid solution. Both do offer a web-based version that
> does work, although with limited functionality.

Other proprietary software such as Zoom and Discord do work correctly.

Basic Zoom usage works, but more advanced workflows such as desktop audio sharing doesn't work at all (but it does in pulseaudio). See the whole story in https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/471

Just report of pulseaudio -> pipewire regressions,
I have Focusrite-Novation Scarlett 2i4 USB to use when I listen via headphones and Bose Mini Soundlink via bluetooth when I listen without. Headphones are normal analog stereo headphones.

Mostly use Google Chrome and normal sites like YT/Twitch.

With pulseaudio I would get seamless (well small hickup, but no actions required) when I switched between those two.

Now with Fedora 33:

pipewire0.2-libs-0.2.7-4.fc33.x86_64
pipewire-libs-0.3.23-1.fc33.x86_64
pipewire-0.3.23-1.fc33.x86_64
pipewire-gstreamer-0.3.23-1.fc33.x86_64
pipewire-utils-0.3.23-1.fc33.x86_64
pipewire-pulseaudio-0.3.23-1.fc33.x86_64
pipewire-alsa-0.3.23-1.fc33.x86_64
pipewire-jack-audio-connection-kit-0.3.23-1.fc33.x86_64
bluez-5.56-1.fc33.x86_64
gnome-settings-daemon-3.38.1-1.fc33.x86_64

$ uname -r
5.10.21-200.fc33.x86_64

After I added, playback works mostly okay,
$ cat .config/systemd/user/pipewire-pulse.service.d/override.conf 
[Service]
Environment=PIPEWIRE_LATENCY=1024/48000 PIPEWIRE_LINK_PASSIVE=1

512/48000 was not okay

Bose is not enabled by default or remembered. I need to power on Bose, playback does stutter slightly (like pulseaudio), but not moved to Bose. I need to go to pavucontrol and from Configuration menu enable Bose Profile (Off (unplugged) -> High Fidelity Playback (A2DP Sink, codec SBC)). And now sound is transferred from headphones to Bose. If I power off Bose, playback is paused totally (video paused and so on). Audio does not move to headphones until I go to pavucontrol Playback and select output device as "Scarlett 2i4 Analog Surround 4.0".

This time shutting down Bose did not break connection from Bluetooth settings. Also at pavucontrol I seem not to be able to change Bose as Off, it stays as "High Fidelity Playback (A2DP Sink, codec SBC)". Also after changing to headphones, Gnome Settings, Sound, changing Output Device does not do anything and Bose is there even if it is powered off.

Another time Bose was actually removed from Bluetooth setting and sound disappeared. I was not able to restore sound via pavucontrol / Gnome Settings, Sound. Also video playback was affected and went to like 15 frames per minute. But Gnome Settings, Sound after I moved Fade from Rear to middle, I got Test Front Left, Front Right working. I guess I need to restart session to restore the sound.

This is regression compared to pulseaudio, I just needed to power on Bose to move audio to there and power off to move audio to headphones. No pauses, just minor temporary slowing during transition. Now I need to use pavucontrol to manage audio and there is need for extra clicks.

If I play with Gnome Settings, Sound, levels L-R F-B, there is syslog entries like:
pipewire-pulse[368566]: pulse-server 0x562af347b5a0: [PulseAudio Volume Control] ERROR command:87 (EXTENSION) tag:19 error:19 (Operation not supported)

Also pw-dump writes colors when dumping to a file and pw-cli dump is not able to do dump as json.

Example log when I had other setting than 1024/48000:
[11396.529459] pipewire[2648]: (bluez_output.<HEX>.a2dp-sink-107) client too slow! rate:256/48000 pos:202672128 status:triggered
[62030.867375] pipewire-pulse[368566]: (PulseAudio Volume Control-16) client missed 1 wakeups
[62050.070014] pipewire-pulse[368566]: (Google Chrome-29) client missed 1 wakeups
16568.948670] pipewire[2648]: (Google Chrome-100) client too slow! rate:512/48000 pos:450948352 status:triggered
[16958.973547] pipewire[2648]: (bluez_output.<HEX>.a2dp-sink-107) client too slow! rate:512/48000 pos:469669632 status:triggered
[59617.306431] pipewire[2648]: (PulseAudio Volume Control-29) client too slow! rate:1024/48000 pos:182241792 status:triggered
[92158.208138] pipewire[2648]: (bluez_output.<HEX>.a2dp-sink-116) client too slow! rate:512/48000 pos:22432768 status:triggered

Services are setup as:

     Loaded: loaded (/usr/lib/systemd/user/pipewire.socket; enabled; vendor preset: enabled)
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; enabled; vendor preset: enabled)
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; vendor preset: disabled)
     Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.service; disabled; vendor preset: disabled)

After a couple of weeks running the branched beta I have switched back to pulseaudio mostly because a regression with firefox: closing a tab that is playing a video (even if the sound is muted) freezes the whole browser for several seconds. This is not happening with pulseaudio.

What would be the best way to get the relevant logs and debug this problem?

> After a couple of weeks running the branched beta I have switched back to pulseaudio mostly because a regression with firefox: closing a tab that is playing a video (even if the > sound is muted) freezes the whole browser for several seconds. This is not happening with pulseaudio.

What version did you try this with? I can't reproduce this. It sounds like a timeout when trying to flush the stream, which
was fixed some time ago. latest version is here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-219efa2b61

> What would be the best way to get the relevant logs and debug this problem?

something like this:

 systemctl --user stop pipewire-pulse.service pipewire-pulse.socket

 PIPEWIRE_DEBUG=3 pipewire-pulse 2>log

then do the misbehaving operations, then append the log here.

Now that I have switched back to pipewire I am not experiencing the issue anymore. I have checked and and the current and previous versions are the same (pipewire-pulseaudio.x86_64 0.3.24-1.fc34). Maybe it is something only happening on long running firefox/pipewire sessions?

Anyway, I have found some relevant entries on the journal log when the problem was happening. See the following attachment

Created attachment 1766696 [details]
journal logs from pipewire & firefox when the freezes were happening

Speech-dispatcher should probably be disabled if you are not using accessibility, it causes excessive load and xruns.

(In reply to Wim Taymans from comment #16)
> Speech-dispatcher should probably be disabled if you are not using
> accessibility, it causes excessive load and xruns.

While accessibility is important, it would be nice if this wasn't running when not needed. For most setups it is a 50 M dependency we don't need and would prefer to not have installed by default.

(In reply to Mads Kiilerich from comment #17)
> (In reply to Wim Taymans from comment #16)
> > Speech-dispatcher should probably be disabled if you are not using
> > accessibility, it causes excessive load and xruns.
> 
> While accessibility is important, it would be nice if this wasn't running
> when not needed. For most setups it is a 50 M dependency we don't need and
> would prefer to not have installed by default.

It would be totally unacceptable to not have it installed by default, since we have no way of knowing when it will be needed. 50MB is a small price to pay for making sure people *can* use our stuff.

Last fedora pipewire version (0.3.24-4), bluetooth seems to work well. But: when starting an external Bluetooth audio device already coupled, is recognized and activated automatically by the bluetooth subsystem, but is not visible by pipewire (qjackctl). Restarting pipewire (systemctl --user restart pipewire) the device is disconnected. Activating the device by hand from the bluetooth panel made pipewire finally works.

One thing I'm worried about with this change is pipewire's apparent tendency to just not want to start up if it can't understand a slightly older version of one of its own configuration files. We have one case of this documented for upgrades to F34 in common bugs:

https://fedoraproject.org/wiki/Common_F34_bugs#pipewire-upgrade-config
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1931384

and another case of it was reported as a comment on the 0.3.24 update:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-2c994d0609#comment-1949412

I really don't think this is an acceptable standard for our core audio server. I don't recall that pulseaudio or any other predecessor ever behaved in this way. I've filed an issue on this upstream - https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/1053 - and I think it would be good if pipewire devs could commit to this never happening again with future versions.

Closing Changes Tracking bugs for the Fedora Linux 34 release. If your change did not make it into the release, please reopen and needinfo bcotton.