Random "Dummy Output" killing audio

After rummaging the web for a while, I've yet to find anyone with this particular issue:
Audio (HDMI from Dell desktop PC to a surround stereo) worked great with Ubu-Mate for about a year. Lately at seemingly random times, there's no audio. When I then go to the Audio Indicator Applet in my Panel and click Sound Settings (aka Sound Preferences), the only option in the Output tab is Dummy Audio. When sound is working the only option there is
Built-in Audio Digital Stereo (HDMI)
The only way I've found to get sound working again is reboot. I've read a number of fixes, but none seem related to audio that normally works but will randomly go Dummy. The only thing I've tried is getting rid of timidity and its daemon, but neither seems to have been installed.

System: 20.04.3, Linux 5.4.0-81-generic x86_64, MATE 1.24.0, 11.5G RAM.

In the /etc/pulse/ daemon.conf and client.conf files every line starts with a semicolon which I imagine is commenting it out, but in the case of the daemon.conf file this one line lacks the leading semicolon:
deferred-volume-safety-margin-usec = 1
It looks like most stuff is set in the default.pa and system.pa files. All of these files have mod dates of 20/07/15 so maybe aren't involved.

The /etc/pulse/client.conf.d directory has a mod date of 21/08/03 though the dead audio happened before that. The only thing in there is a dead link named 01-enable-autospawn.conf mod date 21/05/25 that maybe is relevant? The link target is /run/pulseaudio-enable-autospawn and there's nothing named pulseaudio in the /run directory.

Any ideas?

1 Like

Can confirm. A kernel update a few weeks ago borked the audio in exactly this way, after suspend, on my Dad's Dell. (Which is the common factor).

Moving him to the 18.04 HWE stack (i.e. the 20.04 kernel) improved things to "at random" rather than "every time without fail", but it still happens about half the time on average.

Since I don't have possession of the machine, I had to just give up at that point and hope it gets fixed eventually. If you're willing to grind through trying to help the (Ubuntu) kernel team, you can file it on launchpad. The first thing they'll ask you to do is test with the current mainline kernel, which is fairly easy and not harmful, so please do if you can spare the time.

1 Like

It hasn't happened for a few days, so at this point I'm hoping they've already fixed it in one of the updates. If it starts doing the Dummy again often, I might try to figure out how to file on launchpad. The difficulty there would probably be with how irregular it is. Maybe I could track everything I've done since a reboot and find a reliable way to call the Dummy.

On Dad's machine it only happens after a suspend. That said, the only thing he uses that machine for is chatting on Discord, so when he's not doing that it's asleep all the time.

Since you're on the same kernel he now is, I'd expect the same behavior on yours, i.e. intermittent. As you say, it's possible it was fixed in the most recent kernel update, but I doubt it. We'll see. :slight_smile:

1 Like

Thanks for the followup. :slightly_smiling_face:
I'll probably wreak havoc on my system by typing this on it, but (shhh...) :shushing_face: it's been working fine sine I posted here.
There have been a few updates, so maybe the Ubu/Mate wizards have already found and fixed it. I'd been thinking it was a VLC issue since I use that a lot and it's where I discovered the Dummy due to not using audio for anything else. Well, except for system alert chimes that get ignored anyway presuming there's an onscreen notification.
Anyway, hope it keeps working and that your Dad's does too. :crossed_fingers:

I have been hoping to figure out what is causing some of my audio issues with Ubutu Mate release 20.04.3 LTS (Focal Fossa) 64-bit also. I get blurry sounds and slow (frame-by-frame) video until I reboot. I don't always have to reboot, though. This happens when I view videos on Facebook or Youtube, and I suspect some sort of viral behavior from those platforms and web sites that are attempting something that I don't want them to do to my system.

But today I did notice some notice of dummy hardware or such when I unplugged my external speakers and substituted headphones. I fiddled with the settings a bit and was able to continue without a reboot. All I can say is that I commiserate because I am having to reboot often due to audio issues. Other than that, though, I am really enjoying Ubuntu MATE.

I am running on a Raspberry Pi 4B. It happens on both 4GB and 8GB RAM computers. I don't have a swap file set up either - not sure if that could be a consideration.

1 Like

I've been distracted with many other things, and concurrently had only a couple of Dummy Audio episodes. The audio issue seems to happen mostly or always after putting a DVD from my video library onto my Dell 93" desktop. They're much more convenient to view that way, and MakeMKV coupled with manual struggle with scratch removal enables playing long lost movies that still crash on DVD players. To save space, I then run the ~5GB file through Handbrake and play the <1GB file with VLC. Benefits in this lengthy process go beyond recovering damaged discs to add easy backup on HDD, and best of all the whole slate of features VLC brings. I routinely speed up slow parts of movies and vice versa, easily replay key scenes, and tweak video to bring out shadows or recover blown out highlights, punch up chroma, etc.

I mention all this because for whatever reason(s), this process that seemed likely to be causing the Dummy Audio hassle now doesn't seem to be doing it nearly as much. I think maybe once or twice since my initial 8/25 post if I recall correctly. I've done maybe half a dozen of the DVD recoveries, so something has changed.

I'm still hoping someone may offer ideas on how to switch Dummy Audio back to HDMI/Display Port because it would help anyone encountering this issue, since it seems relevant to people beyond my specific use case.

To see that Dummy Audio setting I'm using a bottom Panel with the Indicator Applet:
I click on the "speaker" icon in the middle of the snip above, and it pops up this pref box:

It opens in the Sound Effects tab (left most, grayed out above because I've already clicked the Output tab). This is how that looks when audio is working, and when it's not the Connector pulldown bar at the bottom says Dummy Audio. Despite the pulldown arrow, there's only one item available in either case - HDMI/Display Port when audio's working, and Dummy Audio when it's not. I guess there's a good reason there's no other option in either case, but the option displayed there reliably matches the availability of audio. As noted previously, the only way to get audio back is to reboot.

Seems like your problem may be the same. When and how do you see the dummy hardware message?

I think it's very unlikely that jomyer's problem is actually the same, given that the Pi hardware is completely different, but there is one thing that's just come to mind: PulseAudio has multiple unwise default behaviors, including things like "shutting down" sinks (i.e. outputs) if they're idle for a few seconds. This means literally powering them off (and can be heard as such if connected to powered speakers, which "pop" each time power is restored). If you're experiencing problems with outputs vanishing WITHOUT suspending the machine, that code is almost certainly the cause.

The relevant piece for this, in /etc/pulse/default.pa, is load-module module-suspend-on-idle. Try commenting that out, and see if things improve.
(module-switch-on-port-available also has some seriously braindead issues with it, but seems unlikely to the be the cause of this. Probably worth a shot to disable that too though, once you've exhausted the other options).

I'm still 99% sure the root of the problem is a bad kernel patch rather than PA though, for once.

1 Like

I was wondering about P.A. but it seems complex enough to scare me off messing with config files, especially since it's not happening as much now. Of course, no sooner had I begun to notice it no longer happening, it happened - but this time there seemed to be a pattern.

I've been intermittently copying my old DVDs to HDD with MakeMKV to play them with VLC instead of the aging and annoying DVD player. (another benefit is stacking the copied discs onto an old CDR spindle rather than shelves of DVD cases)

Anyway, I then run them thru HandBrake to downsize them to save HDD space (like 1/5-1/10 the size, and very little quality loss - sometimes even better). So what I just noticed is that when I then play one in VLC and Suspend the computer afterward - Dummy Audio upon Resume. There's another funky thing happening with VLC, tho less often lately, where closing VLC while it's playing will leave a phantom process open and showing on the panel. So maybe this whole Dummy thing is another intermittent VLC issue.

Happily, not once. It's only occasionally when Resuming from Suspend.

Now that it's seldom happening and seems related to VLC, I'm reluctant to mess with anything. What I might do is see if the VLC is a Snap and thus outdated. If so I could consider installing the latest version to see if it's been fixed.

Well, it's rare enough now that I'll probably just tolerate it for a while unless someone with this particular problem has found a fix. At this point, given the other glitch it wouldn't surprise me if it's actually the way this VLC version integrates with this particular HW/app/OS combo.

Thank you for the followup, arQon.

Just a random idea, it might be nothing but OTOH you never know :

In VLC you can choose the audio output.
It should default to pulse-audio but you can overrule that and let VLC talk to ALSA (the audio driver) directly. This 'steals' that audio hardware from pulse-audio so it disappears from pulse-audio's device list.
As long as VLC is active (even in background) pulse-audio can't use (or see) this hardware.

It might be an idea to check the sound settings of VLC.
if sound output is 'auto' or 'ALSA' , switch it to 'pulse-audio' and see if that solves the problem.

1 Like

Thanks for the exciting idea! It makes perfect sense. :slightly_smiling_face:

So you can imagine my disappointment upon making time to test it. I was sad when the Dummy next showed up. After manually changing the VLC pref from Automatic to pulse-audio, it still worked fine. Until the next time I used Suspend from the Shut Down applet added to the Panel in my desktop Dell. When I Resumed the silence of the deamonic Dummy was deafening. :japanese_ogre:

In addition to VLC, MakeMKV and HandBrake, the issue seems related to Suspend. In fact, I think it may be related to long-term Suspend of half an hour or more. I've tried Suspend for a minute or so, and it wakes with normal audio but when left for half an hour or more the Dummy shows up. Sure is a freaky problem, and I'll be glad when done backing up the rest of my DVD collection. It's a fairly minor problem really, in that this PC reboots in about 20 seconds.

Meanwhile, I'm appreciating the kindness of everyone who's offered help with this.

Update: It seems reliably produced by running Handbrake 1.3.1 to downsize an MKV file and then using Suspend. It may also require actually processing a file. After launching Handbrake just now to get the version number, I did a Suspend/Resume and ... no Dummy. There may also be a requirement for running MakeMKV or VLC, but running just those two apps did not do the Dummy - until I then ran Handbrake on a file and did Suspend/Resume. Maybe nobody else is using this combo of apps on a Dell desktop with UbuMate 20.04, or there's something related to one of my other apps. Several like my workhorse Nemo 4.4.2 are KDE I think. Meanwhile, our library has started selling surplus used DVDs for $1 so this niggling problem will probably continue indefinitely. Maybe 20.10 will fix it, but I'm holding off a while longer before wading into that. Anyway, thanks again for the suggestions and may you have a Happy Halloween (with no mute Dummies) :wink: