Bug 2011231

Proposed as a Blocker for 35-final by Fedora user frantisekz using the blocker tracking app because:

 The installed system must be able to play back sound with gstreamer-based applications.

This might not be that bad to be a blocker, proposing up for a discussion. Workaround exists, it's nothing difficult.

Hey Frantisek, a couple screenshots or a short video would help us non-KDE users better understand how difficult this is to resolve for an end user. Thanks.

> HDMI output is missing.

Where is it missing? You say you can configure it in System Settings, so it's probably not missing there. So where?

(In reply to Kamil Páral from comment #2)
> Where is it missing? You say you can configure it in System Settings, so
> it's probably not missing there. So where?

It's missing in audio indicon "quick menu" in the panel and it's missing in the system settings. As I understand it, these are the only location when you can select Audio Output device.

It's visible only in the configure dialog in the system settings (sort of an advanced menu that you can open), where you can assign profiles that'd fix/workaround the issue.

I'll upload a video demonstrating the issue and fixing it soon.

Created attachment 1829807 [details]
Recording of an issue

Could this be related to the wireplumber bug (BZ 2010683)? If you replace wireplumber with pipewire-media-session, does it behave as expected?

(In reply to Ben Cotton from comment #5)
> Could this be related to the wireplumber bug (BZ 2010683)? If you replace
> wireplumber with pipewire-media-session, does it behave as expected?

No, replacing wireplumber with pipewire-media-session didn't solve the issue.

People are a bit reluctant to vote as blocker, but there is +4 for FE in https://pagure.io/fedora-qa/blocker-review/issue/511 , so marking as an accepted FE.

Discussed during the 2021-10-11 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as we agreed that this seems too limited in impact (at least to HDMI audio output on KDE, and possibly to the specific device) to be considered a criteria violation. Note that it is already accepted as an FE issue.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-10-11/f35-blocker-review.2021-10-11-16.00.txt

I upgraded yesterday to F35 and I'm also affected by this bug.

I think it's far worst that it seems at first message. In my experience, when I press the configure button at the bottom of the audio configure module, it appears an almost blank screen with no options or buttons

https://i.imgur.com/du7qWHX.png

How I am supposed to give a profile to my audio device if I don't have any options on the corresponding configuration module?

But it's even worst, because when I connect an audio device to the jack port, it doesn't get detected both by plasma audio applet and the configuration module. And if I open the pulseaudio configuration program, it doesn't appear it either.

So I think it doesn't just affect HDMI devices, which is a serious problem by its own, because lots of hdmi monitors with integrated speakers are connected through an hdmi port and people expect them to be capable to play some audio. But also affect other types of audio devices (I wonder if it just depends of whether an hdmi device is connected or not, but since my hdmi device is a monitor, it would be a bit tricky to test this for me) and it may not have an obvious way to solve the issue by using the graphical tools provided by the OS.

I think this is an evident candidate to be a blocker bug and it should be revoted.

As a workaround, downgrading pipewire to the f34 version makes everything work again.

It's definitely a pain when you hit it, but OTOH, not many people seem to be hitting it. Your report actually suggests it may not be as simple as "HDMI devices", even - it may be some other factor entirely which results in this happening, which we haven't identified yet. But we don't really have any data indicating a *lot* of people are seeing it, yet, that I'm aware of.

Could someone report this upstream to KDE, since it seems to be a KDE-specific issue?

https://bugs.kde.org/show_bug.cgi?id=426108

This seems to be the upstream equivalent of this bug.

I saw that bug too, but I don't think so. It's from a long time ago, and the symptoms don't quite seem to match.

Hello,
I am just a user.
I have noticed this change in behavior and thought it was a new feature.
Actually I find it very neat to be able to disable the audio devices that you don't want to use.

The audio device I use is the onboard audio device. The fact that the devices without profile don't appear in the list is good for me.

I manage also my girlfriend's computer who isn't as advanced as me. Not having the hdmi device in the list avoid any error or misconfiguration that she could make.

Is this really a bug? That is my question...

(In reply to Monkey Bizness from comment #13)
> Hello,
> I am just a user.
> I have noticed this change in behavior and thought it was a new feature.
> Actually I find it very neat to be able to disable the audio devices that
> you don't want to use.
> 
> The audio device I use is the onboard audio device. The fact that the
> devices without profile don't appear in the list is good for me.
> 
> I manage also my girlfriend's computer who isn't as advanced as me. Not
> having the hdmi device in the list avoid any error or misconfiguration that
> she could make.
> 
> Is this really a bug? That is my question...

You could manually disable HDMI devices before this bug appeared. Besides, I think it's important when a device is connected to have a feedback which allows the user to know it's working. If them the user wants to have the device disabled, that's their choice.

I downloaded the last RC of almost all spins (minus i3) and after trying all of them I've managed to reproduce the bug as initially described in the first report in all of them, including workstation. In the last one, it's present in a bit different way. Instead of the user having to choose a profile in order to make the device work, it appears as disabled and the internal audio is preferred, even if there isn't other device connected. The user has to select the HDMI output as preferred in order to have sound.

The rest of the spins behave as initially described, except KDE spin, in which it's impossible in my experience enable the HDMI output through the audio configuration module because it appears an almost blank screen without options.

Since downgrading to f34's pipewire is a workaround for the issue (dnf downgrade pipewire* --releasever=34) I believe pipewire is the cause of this bug. I don't know what could have been changed since the package version number from the f34 and f35 versions were the same until today. Because a new pipewire version has been pushed to the updates-testing repos, but it doesn't solve the issue either.

https://fedoraproject.org/wiki/Changes/WirePlumber

I believe this could be the cause of the bug, since it's the main difference between f34 pipewire and f35's. I'll try later to switch back to pipewire-media-session.

After doing some test I've discovered the following:

- Replacing wireplumber with pipewire-media-session makes sound work again with upgraded pipewire. I see on a previous message that someone tried and didn't worked. I don´t know why, but definitely it worked for me.

- I tried then replacing the default profile on audio configuration to "Pro Audio" and then I switched back to wireplumber.

- After doing that and rebooting, I've managed to reproduce this bug under KDE as originally described. Inside the audio configuration module, both audio devices, hdmi and internal, appeared as disabled and they only activate after assigning a profile to the HDMI device. I just tried using the default profile and it worked.

So now I have a functional audio on my PC with everything upgraded. But the problem with default configuration on the KDE Spin remains. As I related yesterday, with KDE live image the audio can't be configured on the same hardware because under the configuration module it appears a screen without buttons or any option.

As I told yesterday, with the rest of spins the problem exists but is not as severe (they exist exactly as originally described on this bug), but definitely annoying. Audio devices should be capable of playing audio after connected, not only to give an immediate feedback to the user that they are working, but also because these could be the only audio device connected and it's a mess that it's disabled by default.

I tried the live image too on a PC which doesn't have any HDMI devices connected and everything worked there as expected. So I believe that the bug appears when a HDMI device is connected, even if in my experience when it happens, affects every audio device from the computer.

CCing Wim for the pipewire/wireplumber angle here. Wim, as per several comments above, this bug does seem to involve pipewire or wireplumber or both; Carlos says he can fix it by switching in pipewire-media-session or downgrading pipewire. Frantisek said pipewire-media-session didn't help him - Frantisek, could you reconfirm that, and check whether downgrading pipewire helps?

The 'I see no devices at all, nothing is working' bug is usually because no session manager is started, possibly because during the upgrade (and switch to wireplumber) the service file was not activated due to reordering of the packages. I believe Neil pushed a workaround for that.

HDMI profiles switched to Off Profile (with no HDMI device) is usually because PipeWire/ALSA does not detect anything plugged in to the HDMI ports and so it does not want to automatically switch to something that it thinks is not available. You can manually force it, which is what the manual action when switching the profile does but it won't be remembered. To be sure about this, the output of `pw-dump` can tell us what is going on (`Device.params.EnumProfile[*].available`). If this is the case, it requires an ALSA/driver fix.

(In reply to Wim Taymans from comment #19)
> HDMI profiles switched to Off Profile (with no HDMI device) is usually
> because PipeWire/ALSA does not detect anything plugged in to the HDMI ports
> and so it does not want to automatically switch to something that it thinks
> is not available. You can manually force it, which is what the manual action
> when switching the profile does but it won't be remembered. To be sure about
> this, the output of `pw-dump` can tell us what is going on
> (`Device.params.EnumProfile[*].available`). If this is the case, it requires
> an ALSA/driver fix.

I'll test this again later today without wireplumber. The weird thing imo was the fact that the same configuration (both HW and SW) worked on Workstation as expected and didn't on KDE (until you switched the profile there).

Frantisek, can you confirm that you had a monitor connected to the HDMI port at the time of encountering the bug?

(In reply to Adam Williamson from comment #21)
> Frantisek, can you confirm that you had a monitor connected to the HDMI port
> at the time of encountering the bug?

Yes, I had, this is the only connected monitor (actually, a TV) to the PC.

(In reply to Wim Taymans from comment #19)
> The 'I see no devices at all, nothing is working' bug is usually because no
> session manager is started, possibly because during the upgrade (and switch
> to wireplumber) the service file was not activated due to reordering of the
> packages. I believe Neil pushed a workaround for that.

This is my situation: wireplumber not running (and no unit file) so nothing in applet, nothing in settings app, nothing in configure menu of settings. I think I can write a unit file but as a default state I think this will trip up people less comfortable with systemd. More details below.

Screenshots: https://imgur.com/a/uWRtzjj

System: F35, upgraded from F34 where things worked well.

Packages:
pipewire-0.3.39-1.fc35
wireplumber-0.4.4-2.fc35

Quick pgrep for pipewire shows two process, nothing for wireplumber. From looking at the wireplumber docs I tried to start wireplumber with systemctl:
https://pipewire.pages.freedesktop.org/wireplumber/running-wireplumber-daemon.html

# systemctl --user --now enable wireplumber
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
# systemctl status wireplumber.service
Unit wireplumber.service could not be found.

Kevin: you likely ran into https://bugzilla.redhat.com/show_bug.cgi?id=2016253 . The first command you ran is correct, but you need to run it as *your regular user*, not as root. wireplumber runs in the user session, not the system session. See also https://fedoraproject.org/wiki/Common_F35_bugs#no-sound-on-upgrade .

Thanks Adam! Yes, I think I had 2016253. That makes sense on --user option. I had already got it working by swapping to pipewire-media-session and back.

I did confirm I have this bug as well with a TCL RokuTV. It is resolved by applying a profile.

Screenshots: https://imgur.com/a/a6Y9nus

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Frantisek, any news here? Can you confirm if this is or isn't still an issue on F36/F37? Thanks!

Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13.

Fedora Linux 35 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days