I've had this for long enough - say ten days - to see a consistent behaviour, where it seemed random.
If I leave the computer off for just a couple of hours, sound comes back OK.
If I leave it off all night, it comes back not working. Which is rather weird and unexplainable behaviour, but it's what I get.

I've made an alias to run the sound test, after which the device is recognised, so it's a minor annoyance... let's hope we get an update that fixes it soon, though.
Neon User 20.04.

Don B. Cilly wrote:I've had this for long enough - say ten days - to see a consistent behaviour, where it seemed random.
If I leave the computer off for just a couple of hours, sound comes back OK.
If I leave it off all night, it comes back not working. Which is rather weird and unexplainable behaviour, but it's what I get.

I've made an alias to run the sound test, after which the device is recognised, so it's a minor annoyance... let's hope we get an update that fixes it soon, though.
Neon User 20.04.

Did you try the proposed fix/workaround? (downgrading pipewire)

I'm trying the downgrade as my lappies had pipewire-media-session -d bluez5 consuming 100% cpu randomly and no sound outputs apart from "Dummy Output".

After downgrade, I used "sudo apt-mark hold pipewire" to stop it upgrading, then pulseaudio -k and pulseaudio --start as user.

danielcirco wrote:Did you try the proposed fix/workaround? (downgrading pipewire)

No. I can't be bothered really. Hopefully it will be fixed soon :·)

It seems i have found a more permanent workaround.
I added this as an autostart entry:

Code: Select all

sh -c "systemctl --user stop pipewire;systemctl --user stop pipewire.socket"

claydoh wrote:Try running pulseaudio -k, then delete the ~/.config/pulse and any pulse related file in the top level of your home dir. This will cause all the sound detection and configs to be recreated.
You might have to run pulseaudio -k again after deleting the files.

It worked for me after a reboot, thanks.

Operating System: KDE neon 5.19 (based in Ubuntu 20.04)
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.0
Kernel Version: 4.15.0-117-generic (because under 5 series doesn't work suspending in my computer)
OS Type: 64-bit
Processors: 2 × Pentium® Dual-Core CPU T4200 @ 2.00GHz- ACER Extensa 5635ZG

rechapita wrote:It seems i have found a more permanent workaround.
I added this as an autostart entry:

Code: Select all

sh -c "systemctl --user stop pipewire;systemctl --user stop pipewire.socket"

I don't know where to add this line. Out of curiosity, where do yo add this line?

What I did was to make a bash script with those lines and one extra line and add it to autostart and also worked

Code: Select all

                                                                                               #/usr/bin/sh
systemctl --user stop pipewire;
systemctl --user stop pipewire.socket;
systemctl --user restart pulseaudio;


Will add it to the accepted solutions and workarounds.

Not sure why or what happened in my circumstance, but after the latest kernel upgrade and reboot: Somehow in Audio settings: "Audio" > "Advanced" > "Built-in Audio" Somehow after the upgrade and reboot it changed it to "Profile: Analog Stereo Input" it should be: "Profile: Analog Stereo Output".

Hopefully yours is this easy.

Hello guys!
I found what seems like a permanent fix for the "Dummy Output" issue.

You need to add

Code: Select all

options snd-hda-intel model=generic

at the end of the

Code: Select all

/etc/modprobe.d/alsa-base.conf

file. Do not modify anything else in this file!

Source: https://www.linuxuprising.com/2018/06/f ... ue-in.html

neonwind wrote:Hello guys!
I found what seems like a permanent fix for the "Dummy Output" issue.

You need to add

Code: Select all

options snd-hda-intel model=generic

at the end of the

Code: Select all

/etc/modprobe.d/alsa-base.conf

file. Do not modify anything else in this file!

Source: https://www.linuxuprising.com/2018/06/f ... ue-in.html

For me it didn't work, I think that's a different error with similar symptoms.
I will change the subject of the post to be more clear that this is a problem caused by pipewire 0.3.8-1 update.
Thanks sharing you fix

Questions as I still have no sound and have tried various fixes and for awhile had a tedious workaround that functioned for a time after startup before disappearing:

Is there an accepted fix?
Are there accepted workarounds in some location in forum.kde.org?

I do have the snd_hda_intel
I have NVIDIA Corporation TU104 HD and [AMD] Starship/Matisse HD Audio Controller, both on an Asus TUF Gaming X570 Plus (WiFi) motherboard using the snd_hda_intel kernal driver.
I have not implemented a change to pipewire -- is that essential and how is it best done?
I did the changes in https://www.linuxuprising.com/2018/06/f ... ue-in.html and managed to kill my tedious workaround.

Should I just hold my breath and wait for a kernel fix?

Update:
I have at least intermittent sound back with my tedious workaround after removing the
options snd-hda-intel model=generic
from /etc/modprobe.d/alsa-base.conf
AND
doing the sudo aptitude install pipewire=0.2.7-1 and pulseaudio -k and removing .config/pulse

I have a workaround for now.
Question: why dropping of powered and plugged in (to HDMI 3 controller) to a speaker and no automatic detection of speaker on HDMI port on monitor?

The workaround now is no longer tedious: power on the HDMI connected speaker and reboot.

Unfortunately, keeping the Oontz Angle3 Ultra speaker powered on and connected to the HDMI port on my monitor did not prevent something later dropping that adapter. It disappears from System Settings.

Before the offending update it did not matter whether the HDMI connected adapter was plugged in or not.

I may experiment with using the rear I/O panel connector to the other built in sound chip on the motherboard.

I have a full time hardware workaround: use the rear panel audio connector to the external speaker.

It uses the other, the [AMD] Starship/Matisse HD Audio Controller, and for whatever reason has not been dropped.
I can even power off and power back on the external speaker.

I don't know if my experience would help engineer the bug fix that I hope is coming.

I am experiencing the same issue and have been without analogue audio for a few days after the 20.04 update.

I tried all of downgrading pipewire, editing alsa-base.conf, and removing the pulse config directory from home but nothing has worked.

Hoping somebody will come up with a clever idea on how to fix this.

This is indeed annoying, as it would be interesting to know what things have in fact changed since 18.04 and what would be useful to reset. I'm also wondering if anyone has tried booting from a live stick or doing a fresh installation of Neon 20.04. It'd be interesting to know if this gives the same problem or not.