Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#78012 - [wireplumber] doesn't start pipewire until first audio stream

Attached to Project: Arch Linux
Opened by Christian Thackston (Nan42) - Monday, 27 March 2023, 07:06 GMT
Last edited by Toolybird (Toolybird) - Monday, 27 March 2023, 21:01 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Jan Alexander Steffens (heftig)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description: This bug is (virtually) identical to  FS#72539 , but the former was closed at the request of the OP. The gist of the issue is that Wireplumber does not properly start pipewire.service and pipewire-pulse.service until an audio stream is presented. This is not intended behavior, as it means that there will be an error for the first audio stream every boot which results in no audio output. This can be fixed by running "systemctl --user start wireplumber.service" every boot, before an audio stream is given, but I don't believe this is a good solution.


Additional info:
pipewire 1:0.3.67-1
pipewire-pulse 1:0.3.67-1
wireplumber 0.4.14-1

Steps to reproduce (taken from original bug report; reproduced by me):
1. Reboot & login
2. Check wireplumber.service:
systemctl --user status pipewire-session-manager.service
○ wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
Active: inactive (dead)
3. Run mpv:
mpv file
...
[ao] Failed to initialize audio driver 'pulse'
Could not open/initialize audio device -> no sound.
Audio: no audio

Exiting... (Errors when loading file)
4. Check the service again:
systemctl --user status wireplumber.service
● wireplumber.service - Multimedia Service Session Manager
Loaded: loaded (/usr/lib/systemd/user/wireplumber.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-10-25 13:51:40 EEST; 6s ago
Main PID: 733 (wireplumber)
Tasks: 5 (limit: 16647)
Memory: 11.6M
CPU: 137ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/wireplumber.service
└─733 /usr/bin/wireplumber
This task depends upon

Comment by Toolybird (Toolybird) - Monday, 27 March 2023, 20:18 GMT
Works fine here. It sounds like a problem with your environment and/or config. (You haven't mentioned *anything* about your setup).

I just tested in multiple fresh VM scenarios and no problems whatsoever. I also tried both wireplumber and pipewire-media-session and cannot repro the issue you are seeing.

If this was a widespread problem we would have heard about it by now.
Comment by Christian Thackston (Nan42) - Monday, 27 March 2023, 20:24 GMT
I'm running bspwm/sxhkd and that's pretty much it, very minimal setup. Is the service started explicitly by more fleshed out DE's? As I stated, I could fix the issue by invoking the command myself, but it doesn't work by default. I'll give any information that's required. If my memory is serving me correctly, this hasn't always been an issue on my setup, but I haven't changed any hardware or anything of the sort in a long while. The install is brand new (last night). If you feel that it's a good idea to close this issue because it's too uncommon/non-reproducable, then I understand, it's fixed on my system.

I also forget to mention that mpv now has native pipewire support, so the error message in mpv should be pipewire, not pulse.
Comment by Toolybird (Toolybird) - Monday, 27 March 2023, 21:01 GMT
> very minimal setup. Is the service started explicitly by more fleshed out DE's?

I think so, yes. I just tried again but this time in a minimal sway environment and could kinda repro. The first play produced no sound (but also no error). The 2nd play produced sound as normal.

This probably falls into the category of "if running a minimal WM env, you accept the limitations and config accordingly" or something like that.

Inclined to close this but will seek a PM's opinion.
Comment by Christian Thackston (Nan42) - Monday, 27 March 2023, 21:03 GMT
Ah, I understand. Just as a clarification, the error was with mpv, not pw, so you're issue seems to be the same as mine. I'll consider adding an entry to the arch wiki for this.

Loading...