Random "Dummy Output" killing audio

#1

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)
Stereo
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
#2

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
#3

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.

#4

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
#5

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:

#6

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
#7

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:
panel
I click on the "speaker" icon in the middle of the snip above, and it pops up this pref box:

SoundPrefs
SoundPrefs741×565 52.3 KB

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.

#8

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

#9

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
#10

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.

Sigh...
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.

#11

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
#12

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.

#13

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:

#14

Sadly, after upgrading to 22.04LTS the problem's still randomly there. :neutral_face:

Guess it's time to start digging again. At least for a way to turn audio back on without reboot. I tried killing pulseaudio and restarting it without success. Maybe I need to find out the exact process that's providing audio and restart that, since out on the wild web Dummy Audio seems to be Linux' fallback when the source is lost. Right now when the Dummy's absent, Sound Settings says
Input: Monitor of Built-in Audio Digital Stereo (HDMI)
Output: Built-in Audio Digital Stereo (HDMI) Stereo

That doesn't tell me the actual app(s) responsible for sending audio to pulse, alsa or whatever calls the Dummy when there's no audio.

Well, if all else fails read the directions. So I'm starting in on SoundTroubleshootingProcedure in the Ubuntu docs again. Some of it actually makes sense now, having banged my head on this for a while.

Any pointers?

#15

First off, I'm sad to have been afraid of trying this and want to again express appreciation for the suggestion. Clearly you're expert on this topic arQon and confident that turning off suspend on idle could fix this pervasive and annoying issue that seems to affect a vast array of distros and hardware, with a variety of frustrating manifestations (including no audio at all, so it's lucky mine's intermittent and Suspend related on a fast-booting machine). Anyway, thanks again arQon. :clap:

So feeling a lot more familiar with UbuMate (which is to say advancing to timid beginner) just now I've commented it out. My impression is nothing can change until reboot, which I need to do anyway since the Dummy appeared after a mixture of ShotCut / VLC / Handbrake session that ended with me leaving the latter chewing on several large MKV movie files overnight. When that ended sometime in the wee hours, the PC auto-suspended during the inactivity.

This morning I woke it into Dummy mode, motivated to finally give this a shot. If it creates a new problem, I'll be right back with an update. I'm also going to do more of the Handbrake downsizing tonight to make room on my HDD, so it may not be long before I'm back to report on the outcome of that adventure. OTOH, it could be several months until whatever exact behavior on my part has been making a mute zombie out of HDMI audio. Wish me luck, and if I don't post a followup today those with Dummy issues might try this. :crossed_fingers:

#16

Definitely not! :slight_smile:
I just experienced the problem I mentioned on one of my machines (which is not the Dell that seems to share your problem) and fixed it that way, that's all.

As I said in my first comment, I suspect this particular issue is a kernel bug - but that's beyond your ability to even try to resolve, whereas the PA change is much less intimidating, and it has a non-zero chance of fixing things. That made it a good enough idea to suggest despite my lack of confidence in it. Hopefully you'll get lucky though. :slight_smile:

1 Like
#17

Overnight I left Handbrake downsizing some prior DVD files ripped with MakeMKV, cropping a small mkv file with ShotCut, and using VLC to run a minute of video. Woke in Dummy mode. It's not VLC's inability to play because Rythmbox is silent too, as one would expect with the system's Sound Settings reporting the Dummy. I've been so busy, there's no time yet to start reading the directions either. Again glad reboot always fixes it, and is so quick on this machine. :expressionless:

Update: I'm not certain, but it may be more prone to Dummy behavior if the PC goes to sleep automatically after running a process for awhile. Like if Handbrake or maybe MakeMKV is downsizing in the wee hours and the PC sleeps after timeout. I don't recall it ever going mute while actually processing, and probably not when it's done and I manually sleep (with or w/o the suspect apps open).

#18

I've seen this topic progress for an entire year now (give or take a few days). I've tried to figure this out myself, but have never nailed a cause -- I personally don't have this issue.

However, I do have a few remotely similar issues involving kernel 5.15, (very old) Intel integrated graphics, and VLC and Firefox. In my case, randomly (usually after using Firefox for about 20 minutes), the entire screen freezes for five seconds, goes black briefly, then everything starts moving normally again. Except that graphics acceleration is disabled, and all the applications on my desktop run horridly slow and cause my desktop to lock up while they're redrawing the screen. Ditto happens (very predictably) if I accidentally leave VLC running when I suspend the computer; when I resume the computer, everything looks fine until I try to play back a video, at which point VLC drops 99.999% of the video frames, and I discover that graphics acceleration is yet again disabled. In both cases, the only thing that restores graphics acceleration is a reboot.

I know -- your problem is sound-related and mine is graphics-related, and our hardware probably has an age difference of (literally) 19 years. But I find the parallels staggering. In both cases, VLC is involved. In both cases, a suspend triggers the bug. In both cases, the problem is only resolved by a reboot. You're using a 5.4 kernel, so there's no common ground there, but I find it very interesting that my problem only began appearing when I upgraded to 5.15.

In my case, there were some clues left in the kernel message log -- you might want to do a dmesg command right before suspending with HandBrake/VLC/etc open, then suspend the computer, then resume it, then when the Dummy output shows up, run dmesg again and see what messages are new. The MATE System Log Viewer may be useful for this, as it shows new messages in bold. Just keep the Viewer open from before you suspend the computer to after the Dummy output freakiness develops. If you post that log here, maybe I can help.

P.S.: By the way, I don't use PulseAudio on this system, I use straight-up ALSA. This might be the difference between our setups, and may explain why I don't witness the bug whereas you do.

3 Likes
#19

I'm glad you're following it, because it brings hope this could actually be solved. Even if it takes a fix in the kernel. When googling the issue, it does seem to have been a niggling problem for years on a variety of distros.

Interesting idea! Just hope I can remember to do it every time, because I've done some edit sessions recently followed by long suspend (sometimes overnight auto-suspend when I leave a long encode running, which has often brought out the Dummy) and all is still working normally. Such a gnarly nagging problem, that fortunately has a quick solution w/20 second reboot thanks to my nvme root drive. Sure glad I'm not having this on my old MacBooks with a coffee break boot time even after upgrade to SSDs.

Oh, that's a tempting topic! Presumably an entirely new rabbit hole, given the intermittent nature of this issue. I wonder what sorts of freak issues turning off PulseAudio might involve. But if I understand correctly, somehow it's an add-on or front end to ALSA?

#20

If we find the definitive cause of the issue, I may try to write that patch, as a matter of fact. I've done amateur kernel development (privately) in the past.

Tell you what: Instead of running dmesg right before you suspend, just run it after the Dummy Output appears. The dmesg log should always contain a line along the lines of PM: Freezing all tasks..., which is added to the log immediately before the computer actually enters suspend mode. If I get the log output, I'll just look at the lines after that message. No biggie. Now you won't have to remember anything except to run dmesg after the Dummy Output appears.

Yes, applications connect to PulseAudio and PulseAudio uses ALSA; PulseAudio is sort of a "middle-man" in that regard. Also, PulseAudio installs a plug-in to the main ALSA library, so that if an application uses straight-up ALSA (rather than going through PulseAudio), this plug-in will forward all audio from the application to PulseAudio instead. So once PulseAudio is running, it sort of takes over and almost forces all applications to use it.

There are advantages and disadvantages to using straight-up ALSA, though:

One disadvantage is that ALSA doesn't give you as wide a range of volume control settings as does PulseAudio. ALSA only lets you set the volume control to settings that your audio hardware supports; you can't increase the audio volume above 100% (potential distortion territory), for example, using ALSA. PulseAudio does much of the volume adjustment in software, so that theoretically, you can set the volume (almost) anywhere you want it to be -- though that comes at the price of possible distortion.

Another issue is that, according to what I've read, ALSA by itself doesn't interact with HDMI audio very well, especially non-stereo surround sound -- somehow PulseAudio is able to handle 4:1 and other speaker layouts better, even though it's a middle layer between ALSA. :man_shrugging: I've never used surround sound myself, though, so I have no idea if this is true, or if my source (a famous Linux magazine) is blowing hot air.

One last pitfall I can think of: While most applications I know of can work with ALSA, some are moving towards requiring PulseAudio -- after all, who doesn't have PulseAudio these days? :roll_eyes: Firefox has been moving in such a direction for at least the last few years now; I compile Firefox myself with PulseAudio support disabled (among other things), and every time I compile it, it helpfully warns me that the ALSA support is "deprecated" and isn't going to be around forever.

So with all that said, I think we should try to find the underlying problem here, rather than covering it up by bypassing PulseAudio. If/when Mozilla decides we don't need plain ALSA anymore, maybe years from now, you don't want this bug to still exist when you are forced to switch back to PulseAudio, do you?

I look forward to seeing the dmesg log. Take care. :wink:

3 Likes