Pipeware issue in KDE after F34->F35

[Miroslav Suchý]

I hit the same issue for the second time, therefore I strike coincidence.

I have machine upgraded from F34 to F35 (and actually upgraded every 6 month from Fedora-I-dunno). And after the upgrade 
I do not see the sound devices. Therefore there is no sound.

For the first time it magically started working after some time - I have done zilions of things and I am not sure what 
makes it work.

Now I have a second notebook where it does not work, and nothing what I have done on the first machine helped so far.

I am asking here, because I am really not sure what component is causing it (pipewire, KDE, something else).

Some data:

* selinux is out as it happens even in permissive mode

* it is KDE environment (I cannot try  Gnome)

* systemctl--userrestart pipewire-pulse.service

does not help. And status shows, that it is active and running

* pactl info shows:

... PulseAudio (on PipeWire 0.3.38
...

Default Sink: @DEFAULT_SINK@

Default Target: @DEFAULT_SOURCE@

and when I manually run "wireplumber" it shows:

Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo

and the devices appear in KDE and I can play a sound.

Any hints, please?

Miroslav

[Micah Shennum]

> and when I manually run "wireplumber" it shows:
>
> Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
> Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo
>
> and the devices appear in KDE and I can play a sound.

I has the same issue (KDE and all), and fixed it with `systemctl --user 
enable --now wireplumber` and haven't had any issues since, though I 
assume that I've therefor switched over to fully use wireplumber; I 
don't know if that's the right answer for your usecase.

--Micah

[Vít Ondruch]

Dne 19. 10. 21 v 18:30 Micah Shennum napsal(a):
> > and when I manually run "wireplumber" it shows:
> >
> > Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
> > Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo
> >
> > and the devices appear in KDE and I can play a sound.

I had similar issues on my two LPs using gnome.
> I has the same issue (KDE and all), and fixed it with `systemctl 
> --user enable --now wireplumber` and haven't had any issues since, 
> though I assume that I've therefor switched over to fully use 
> wireplumber; I don't know if that's the right answer for your usecase.

This helps but is not right. As I wrote already elsewhere, there is some 
issue. And I believe that the better workaround is something like:

~~~

$ systemctl --no-reload preset --global pipewire-pulse.service
$ systemctl --no-reload preset --global pipewire-pulse.socket

~~~

The symptoms were that one or both of these services had this line in 
their `status` output:

~~~

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

~~~

I don't really how to figure what "disables" the unit file, assuming 
that enabling the pipewire-pulse.* was the right thing to do.

Vít

[Adam Williamson]

On Wed, 2021-10-20 at 14:31 +0200, Vít Ondruch wrote:
> Dne 19. 10. 21 v 18:30 Micah Shennum napsal(a):
> > > and when I manually run "wireplumber" it shows:
> > >
> > > Default Sink: alsa_output.pci-0000_00_1b.0.analog-stereo
> > > Default Source: alsa_input.pci-0000_00_1b.0.analog-stereo
> > >
> > > and the devices appear in KDE and I can play a sound.
>
> I had similar issues on my two LPs using gnome.
> > I has the same issue (KDE and all), and fixed it with `systemctl 
> > --user enable --now wireplumber` and haven't had any issues since, 
> > though I assume that I've therefor switched over to fully use 
> > wireplumber; I don't know if that's the right answer for your usecase.
>
> This helps but is not right. As I wrote already elsewhere, there is some 
> issue. And I believe that the better workaround is something like:
> $ systemctl --no-reload preset --global pipewire-pulse.service
> $ systemctl --no-reload preset --global pipewire-pulse.socket
>
> The symptoms were that one or both of these services had this line in 
> their `status` output:
> Loaded: loaded (/usr/lib/systemd/user/pipewire-pulse.socket; disabled; 
> vendor preset: enabled)

But that's not the problem Miroslav or Micah had, because Miroslav said
pipewire-pulse was enabled and running for him, and if pipewire hadn't
been running already for Micah, enabling wireplumber wouldn't have
helped.

The correct configuration is for pipewire to be enabled in the system
session and wireplumber or pipewire-media-session to be enable in the
user session (wireplumber should be the default). Either of those not
being the case is going to result in broken audio. Both are supposed to
be handled on upgrade from F34 already, but it looks like Neal spotted
a case where it can be missed.

[Kevin Fenzi]

On Sun, Oct 24, 2021 at 11:34:29PM -0700, Adam Williamson wrote:
...snip...
> The correct configuration is for pipewire to be enabled in the system
> session and wireplumber or pipewire-media-session to be enable in the
> user session (wireplumber should be the default). Either of those not
> being the case is going to result in broken audio. Both are supposed to
> be handled on upgrade from F34 already, but it looks like Neal spotted
> a case where it can be missed.

pipewire is a user unit as well.

Can you expand on what you mean by system session?

kevin

[Adam Williamson]

On Mon, 2021-10-25 at 08:48 -0700, Kevin Fenzi wrote:
> On Sun, Oct 24, 2021 at 11:34:29PM -0700, Adam Williamson wrote:
> ...snip...
> > The correct configuration is for pipewire to be enabled in the system
> > session and wireplumber or pipewire-media-session to be enable in the
> > user session (wireplumber should be the default). Either of those not
> > being the case is going to result in broken audio. Both are supposed to
> > be handled on upgrade from F34 already, but it looks like Neal spotted
> > a case where it can be missed.
>
> pipewire is a user unit as well.
>
> Can you expand on what you mean by system session?

Oh, indeed, my mistake, sorry. I thought it was a system unit, for some
reason. So, both should be enabled and running in the user session.

[Tom Seewald]

Looks like someone has reported this bug [1] feel free to add any additional details. I ran into this bug myself and consider it to be a pretty big problem if 34->35 upgrades are going to leave some users without working audio.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2016253

[Neal Gompa]

On Sun, Oct 24, 2021 at 3:52 PM Tom Seewald  wrote:
> Looks like someone has reported this bug [1] feel free to add any additional details. I ran into this bug myself and consider it to be a pretty big problem if 34->35 upgrades are going to leave some users without working audio.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=2016253

I think I have an idea of what's happening and I may be able to fix it.

[Marius Schwarz]

Am 19.10.21 um 17:44 schrieb Miroslav Suchý:
> Any hints, please?

JFYI, pipewire has been replaced by pulseaudio on the Fedora Pinephone 
Edition, because pipewire had issues with profile switching, which 
pulseaudio does not have. We also had missing audio devices, which was 
an interaction between alsa and pipewire.

Try to swap pipewire-pulseaudio with pulseaudio package and recheck your 
issue.

best regards,
Marius Schwarz