Bug 1906086 - Route all Audio to PipeWire
Summary: Route all Audio to PipeWire
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Changes Tracking
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Wim Taymans
QA Contact:
URL:
Whiteboard:
Depends On: 1907300 1907806 1907825 1915790 1916094 1925706 1925790 1927891
Blocks: F34Changes
TreeView+ depends on / blocked
 
Reported: 2020-12-09 16:38 UTC by Ben Cotton
Modified: 2021-04-27 14:30 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-04-27 14:30:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
journal logs from pipewire & firefox when the freezes were happening (26.57 KB, text/plain)
2021-03-26 16:00 UTC, Fernando Herrera
no flags Details

Description Ben Cotton 2020-12-09 16:38:28 UTC
This is a tracking bug for Change: Route all Audio to PipeWire
For more details, see: https://fedoraproject.org/wiki/Changes/DefaultPipeWire

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

Comment 1 Mauro Carvalho Chehab 2020-12-14 21:37:55 UTC
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.

Comment 2 Mauro Carvalho Chehab 2020-12-14 21:39:40 UTC
(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

Comment 3 Chase Lau 2021-02-09 16:09:44 UTC
My Bose QC35's connected via bluetooth stop working after upgrading to Pipewire. I'll investigate more.

Comment 4 Ben Cotton 2021-02-16 15:51:54 UTC
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.

Comment 5 Matt 2021-02-18 22:45:47 UTC
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.

Comment 6 Gabriele Turchi 2021-02-19 14:21:09 UTC
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.

Comment 7 Gabriele Turchi 2021-02-19 20:22:36 UTC
(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.

Comment 8 Gregor Schram 2021-03-06 07:45:02 UTC
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.

Comment 9 Gregor Schram 2021-03-06 07:46:56 UTC
(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.

Comment 10 Yajo 2021-03-06 12:18:37 UTC
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

Comment 11 Markus Linnala 2021-03-13 18:16:21 UTC
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)

Comment 12 Fernando Herrera 2021-03-26 14:13:30 UTC
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?

Comment 13 Wim Taymans 2021-03-26 14:29:42 UTC
> 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.

Comment 14 Fernando Herrera 2021-03-26 15:59:03 UTC
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

Comment 15 Fernando Herrera 2021-03-26 16:00:11 UTC
Created attachment 1766696 [details]
journal logs from pipewire & firefox when the freezes were happening

Comment 16 Wim Taymans 2021-03-26 16:52:49 UTC
Speech-dispatcher should probably be disabled if you are not using accessibility, it causes excessive load and xruns.

Comment 17 Mads Kiilerich 2021-04-09 10:32:24 UTC
(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.

Comment 18 Neal Gompa 2021-04-11 03:16:58 UTC
(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.

Comment 19 Gabriele Turchi 2021-04-12 18:37:10 UTC
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.

Comment 20 Adam Williamson 2021-04-15 00:19:23 UTC
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.

Comment 21 Ben Cotton 2021-04-27 14:30:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.