Pulseaudio breaks HDMI audio on sleep/wake

Bug #1888598 reported by Tessa
164
This bug affects 33 people
Affects Status Importance Assigned to Milestone
pulseaudio (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

on a fresh Ubuntu 20.04 x64 install, I've noticed some troubling bugs with pulseaudio after putting my system to sleep and then waking it up. these bugs aren't present on a fresh boot, only after resuming from sleep:

- it forgets which sound output device it's set to, and always reverse to the motherboard's S/PDIF output.
- I have two devices connected to my video card, one is a displayport monitor, and one is a home theater receiver via HDMI. it confuses the two, and randomly switches which device it thinks is capable of surround sound.
- it sometimes refuses to switch to the correct audio device, and just resets any choice back to the internal S/PDIF, until the system is rebooted.

as you can imagine, this a pretty frustrating state of affairs.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: pulseaudio 1:13.99.1-1ubuntu3.4
ProcVersionSignature: Ubuntu 5.4.0-40.44-generic 5.4.44
Uname: Linux 5.4.0-40-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.4
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: tessa 3387 F.... pulseaudio
 /dev/snd/pcmC1D7p: tessa 3387 F...m pulseaudio
 /dev/snd/controlC2: tessa 3387 F.... pulseaudio
 /dev/snd/controlC0: tessa 3387 F.... pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Wed Jul 22 18:38:42 2020
InstallationDate: Installed on 2020-07-15 (7 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: pulseaudio
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/18/2018
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3503
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: GRYPHON Z97
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3503:bd04/18/2018:svnASUS:pnAllSeries:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnGRYPHONZ97:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.family: ASUS MB
dmi.product.name: All Series
dmi.product.sku: All
dmi.product.version: System Version
dmi.sys.vendor: ASUS

Revision history for this message
Tessa (unit3) wrote :
Revision history for this message
lotuspsychje (lotuspsychje) wrote :

Can you try updating your system to kernel 5.4.0-42-generic
and see if you can reproduce your issue?

Revision history for this message
Hui Wang (hui.wang) wrote :

And you could update the gnome-control-center and redo your test.

sudo apt-get update
sudo apt install gnome-control-center

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Revision history for this message
Tessa (unit3) wrote :

ok, did a dist upgrade, now I'm on kernel 5.4.0-42-generic and gnome-control-center 3.36.4-0ubuntu1. bugs still persist. notably, after sleep/resume:

- defaulted to s/pdif audio
- switched hdmi/dp audio outputs, so i have to use hdmi/dp 2 to get audio out, but it still sees surroundsound only on hdmi/dp 1 (the correct output after a fresh boot), so I completely lose surround sound even after choosing the "working" output
- takes something like 30s to switch audio outputs
- randomly switches back to internal s/pdif

Revision history for this message
Hui Wang (hui.wang) wrote :

I guess when you computer suspends and resumes, the hdmi/dp has a process like plugging out (suspend) and plugging in (resume), so it should have the same behaviour of plugging out and replugging in, no need to run suspend and resume.

And the s/pdif audio will be active after plugging in, this is because the s/pdif belong to <alsa_output.pci-0000_00_1b.0.iec958-stereo> which has higher priority than <alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1>.

You could do a test, update the gnome-control-center to 3.36.4-0ubuntu1 (already done), reboot, plug in the hdmi/dp cable, open the gnome-control-center, select HDMI/DP1 or 2 in the gnome-control-center, then plug out the hdmi/dp cable, now the output will switch to s/pdif automatically, plug in the hdmi/dp cable, does the output switch back to HDMI/DP1 or 2 automatcally?

Revision history for this message
Tessa (unit3) wrote :

Alright, I just ran the test. When I unplug the hdmi cable connected to the receiver, it switches to s/pdif. I left it for 30s, then plugged it back in, and it correctly switched back.

Put it to sleep, woke it up, and the audio outputs were all messed up again. So it's something that's happening during resume which isn't the same as normal hotplug behaviour.

Revision history for this message
Tessa (unit3) wrote :

I should also note, I tested this issue in KDE, and saw the same issues. So it doesn't seem to have anything to do with gnome or the gnome-control-center.

Revision history for this message
Hui Wang (hui.wang) wrote :

after the resume, you run pacmd list-cards, do the hdmi-output-0 and -1 are "available: yes" as below?

  hdmi-output-0: HDMI / DisplayPort (priority 5900, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "video-display"
    device.product.name = "LG Ultra HD
 "
  hdmi-output-1: HDMI / DisplayPort 2 (priority 5800, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "video-display"
    device.product.name = "HTR-5063

Revision history for this message
Tessa (unit3) wrote :

yep, looks like even after sleep and when things are all messed up, they're still listed as available:

 ports:
  hdmi-output-0: HDMI / DisplayPort (priority 5900, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "video-display"
    device.product.name = "LG Ultra HD
 "
  hdmi-output-1: HDMI / DisplayPort 2 (priority 5800, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "video-display"
    device.product.name = "HTR-5063

Revision history for this message
Hui Wang (hui.wang) wrote :

So, let's debug with the pulseaudio log.

Enable the debugging log in the pulsaudio:
edit /usr/lib/systemd/user/pulseaudio.service, comment out the line starting with ExecStart=..., add a new line "ExecStart=/user/bin/pulseaudio -vvvv --log-target=file:/home/your_user_name/pa.log

reboot

Then tail -f ~/pa.log

Plug the hdmi monitor, and select the hdmi audio as output device from UI. now check the pa.log, could you find the "configured_default_sink" from the log, it indicates the change of configured_default_sink.

If the hdmi audio is set to configured_default_sink and keeps unchanged during the suspend and resume, the hdmi audio should be the output device after resume. So please check the changing about configured_default_sink in the pa.log.

Revision history for this message
Tessa (unit3) wrote :

ok, after setting it post-reboot, I see the following setting it as the default in the logs:

4572:I: [pulseaudio] core.c: default_sink: alsa_output.pci-0000_00_1b.0.iec958-stereo -> alsa_output.pci-0000_01_00.1.hdmi-surround

as well as the following active ports with `pactl list`:

 Ports:
  hdmi-output-0: HDMI / DisplayPort (priority: 5900, latency offset: 0 usec, available)
   Properties:
    device.icon_name = "video-display"
    device.product.name = "HTR-5063
    "
   Part of profile(s): output:hdmi-stereo, output:hdmi-surround, output:hdmi-surround71
  hdmi-output-1: HDMI / DisplayPort 2 (priority: 5800, latency offset: 0 usec, available)
   Properties:
    device.icon_name = "video-display"
    device.product.name = "LG Ultra HD
 "
   Part of profile(s): output:hdmi-stereo-extra1, output:hdmi-surround-extra1, output:hdmi-surround71-extra1
  hdmi-output-2: HDMI / DisplayPort 3 (priority: 5700, latency offset: 0 usec, not available)
   Properties:
    device.icon_name = "video-display"
   Part of profile(s): output:hdmi-stereo-extra2, output:hdmi-surround-extra2, output:hdmi-surround71-extra2
  hdmi-output-3: HDMI / DisplayPort 4 (priority: 5600, latency offset: 0 usec, not available)
   Properties:
    device.icon_name = "video-display"
   Part of profile(s): output:hdmi-stereo-extra3, output:hdmi-surround-extra3, output:hdmi-surround71-extra3

I put the machine to sleep for 30s, then wake it, and I see:

4824:I: [pulseaudio] core.c: default_sink: alsa_output.pci-0000_01_00.1.hdmi-surround -> alsa_output.pci-0000_00_1b.0.iec958-stereo

looking in the logs around that time, there's a bunch of errors about the hdmi audio devices, and interestingly, `pactl list` shows my output devices switching ports, even though that doesn't make sense:

 Ports:
  hdmi-output-0: HDMI / DisplayPort (priority: 5900, latency offset: 0 usec, available)
   Properties:
    device.icon_name = "video-display"
    device.product.name = "LG Ultra HD
 "
   Part of profile(s): output:hdmi-stereo, output:hdmi-surround, output:hdmi-surround71
  hdmi-output-1: HDMI / DisplayPort 2 (priority: 5800, latency offset: 0 usec, available)
   Properties:
    device.icon_name = "video-display"
    device.product.name = "HTR-5063
    "
   Part of profile(s): output:hdmi-stereo-extra1, output:hdmi-surround-extra1, output:hdmi-surround71-extra1
  hdmi-output-2: HDMI / DisplayPort 3 (priority: 5700, latency offset: 0 usec, not available)
   Properties:
    device.icon_name = "video-display"
   Part of profile(s): output:hdmi-stereo-extra2, output:hdmi-surround-extra2, output:hdmi-surround71-extra2
  hdmi-output-3: HDMI / DisplayPort 4 (priority: 5600, latency offset: 0 usec, not available)
   Properties:
    device.icon_name = "video-display"
   Part of profile(s): output:hdmi-stereo-extra3, output:hdmi-surround-extra3, output:hdmi-surround71-extra3

Revision history for this message
Hui Wang (hui.wang) wrote :

@Tessa,

could you find "configured_default_sink" instead of "default_sink" from from the log, configured_default_sink is more important than default_sink for audio device switching.

Revision history for this message
Hui Wang (hui.wang) wrote :

And if you couldn't find the configured_xxx, you could use pacmd set-default-sink xxxxx to switch to hdmi audio instead of using your normal way to witch the audio device.

Revision history for this message
Tessa (unit3) wrote :

alright, I see on boot, it changing the configured default when I switch to HDMI audio from p/sdif:

4203:I: [pulseaudio] core.c: configured_default_sink: alsa_output.pci-0000_01_00.1.hdmi-surround-extra1 -> alsa_output.pci-0000_01_00.1.hdmi-surround

and after suspend/resume, there are no new messages about the configured default. is it's not changing my configured default, but it is still messing up the audio devices after sleep.

Revision history for this message
Hui Wang (hui.wang) wrote :

That is weird, could you please upload the pa.log which contains the log of switching to hdmi audio and suspend/resume.

Revision history for this message
Tessa (unit3) wrote :

alright, here's the pa debug log where I did a fresh boot, set audio from s/pdif to the hdmi audio output, then put the machine to sleep and woke it, and then set the audio to the other hdmi output device after the system switched them around.

Revision history for this message
Hui Wang (hui.wang) wrote :

Looks like this is really a PA's defect.

you could test this workaround temporarily:

edit /etc/pulse/default.pa

do some change like this: load-module module-switch-on-connect blacklist=""

I will find a physical machine to debug this issue, and try to find a real solution.

Revision history for this message
Tessa (unit3) wrote :

ok, made that change. it stayed on the correct input after a reboot, and after sleep/resume. however, sleep/resume still messes up the device ordering so i still have to change it to the new "correct" dev after resume. still. headway! :)

Revision history for this message
Tessa (unit3) wrote :

I'm seeing another fun intermittent issue after waking from sleep on my system. sometimes after resume, the audio is really static-y, until i turn the volume down one notch and back up again. next time it happens I'll attach the logs again, just to see if there's anything illuminating there. it only happens maybe ~5% of the time, so it might be a while until I can reproduce.

Revision history for this message
Tessa (unit3) wrote :

and here's another new wrinkle... it looks like after my machine has been put to sleep and woken up a few times, it now creates a new dummy audio device each time, until my system is full of dummy audio devices.

seriously what is up with sleep/wake and pulse in ubuntu 20.04??

Revision history for this message
Hui Wang (hui.wang) wrote :

It is not a common issue, I tried to reproduce it on many machines, but so far can't reproduce the problem. It is not easy to debug without a physical machine to reproduce the problem.

Revision history for this message
Hui Wang (hui.wang) wrote :

@Tessa,

Please collect some log:

fresh booting up, and select hdmi audio as output, then run pacmd list > before.txt

suspend and resume, make sure the output is switched to on-board device,
run pacmd list > after.txt

then upload the before.txt and after.txt.

Revision history for this message
Tessa (unit3) wrote :

before pacmd --list, with the input correctly selected as 5.1 surround on HDMI / DisplayPort 2.

Revision history for this message
Tessa (unit3) wrote :

after pacmd --list, when the system has woken from sleep, and now is on the wrong sound output. note that it's not going to the internal sound card at the moment, but the other hdmi device. even though looking at the diff, it thinks the default sync hasn't changed, it actually is now going to the wrong output, and i have to manually switch it to the other hdmi/dp in the sound settings.

Revision history for this message
Hui Wang (hui.wang) wrote :

According to the log of #18, looks like after resuming, the pulseaudio tried to set the pcm to 5.1 channels on the hdmi-surround-extra1, but failed:

D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(6) failed: Invalid argument
D: [pulseaudio] alsa-util.c: Trying hdmi:2,1 without SND_PCM_NO_AUTO_FORMAT ...
D: [pulseaudio] alsa-util.c: Managed to open hdmi:2,1
I: [pulseaudio] alsa-util.c: Trying to disable ALSA period wakeups, using timers only
D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(6) failed: Invalid argument
D: [pulseaudio] alsa-util.c: Trying plug:hdmi:2,1 with SND_PCM_NO_AUTO_FORMAT ...

could you upload the output of 'cat /proc/asound/$(nvhdmi sound card)/eld*' before and after suspend/resume.

And could you redo the test of #12 and find if there is the error of "snd_pcm_hw_params_set_channels(6) failed" in it?

Revision history for this message
Tessa (unit3) wrote :

the before and after outputs of catting this card are identical according to diff, so I've just included the before output here.

Revision history for this message
Tessa (unit3) wrote :

also, I looked for the error you described, and it's not present, but I do see this:

2539:D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(8) failed: Invalid argument
2542:D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(8) failed: Invalid argument
2545:D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(8) failed: Invalid argument
2548:D: [pulseaudio] alsa-util.c: snd_pcm_hw_params_set_channels(8) failed: Invalid argument
2549:I: [pulseaudio] alsa-util.c: Failed to set hardware parameters on plug:surround71:0: Invalid argument

I imagine this is because my output device is a 7.1 device, not a 5.1 device, but it is still strange that it's even attempting to set a mode that isn't what I configured, but instead the highest-channel mode.

Revision history for this message
Hui Wang (hui.wang) wrote :

So if you only plug the monitor and don't plug the home theater, and choose the output to hdmi monitor, suspend and resume, does the output still on hdmi monitor?

Revision history for this message
Tessa (unit3) wrote :

it appears to, yes. i only tested it a couple times, but it consistently stayed on the same audio output.

Revision history for this message
Hui Wang (hui.wang) wrote :

When you have time please redo the test of comment #12. But this time, don't need to run tail -f ~/pa.log that early.

After you choose 5.1-surround from gnome-setting, run tail -f ~/pa.log, then press "enter" button for a couple of times, this will produce empty lines on the terminal. Then suspend and resume the system, and only copy the log generated during the suspend and resume to a new file (you could easily find the new log because there are empty lines on the terminal as separator). and upload that new log file, don't upload the whole pa.log this time. Let us see what happened during suspend and resume.

thx.

Revision history for this message
Tessa (unit3) wrote :

this is the log entries only post resume. the output is incorrect after resume, as usual.

Revision history for this message
Hui Wang (hui.wang) wrote :

With the log of #33, after resume, the active output device is hdmi-stereo-0 (monitor)?

BTW, it looks like you still use the workaround of #19 (load-module module-switch-on-connect blacklist=""), since this workaround doesn't help, please drop it.

And after dropping the (load-module module-switch-on-connect blacklist=""), please plug your monitor to hdmi/dp port1, and plug your home theatre to hdim/dp port0, then redo the test of #33, and upload a new log.

For the hdmi/dp ports, port0 has higher priority than port1, if hdmi-port0 resume earlier than hdmi-port1, the profile of hdmi-port1 will have no chance to be active.

Revision history for this message
Tessa (unit3) wrote :

"after resume, the active output device is hdmi-stereo-0 (monitor)?" -> as I've noted before, for some reason after resume, it switches around the numbering which output is actually which physical connection. this is could be the root cause of the issue I'm seeing, but given all the other weirdness (dummy audio outputs being created, switching sometimes randomly to the motherboard spdif instead, etc) it's really hard to be sure.

I can't actually switch around the ports. I only have one HDMI output, so that has to go to the home theatre system. and if I plug my monitor into any output but the one it's connected to, the boot prompt to decrypt my drive is invisible and I can't navigate any other boot settings or issues either, as NV cards only display boot output on one display apparently. So I'm stuck with the ordering I have.

That being said, if pulse isn't waiting for everything to wake up after resume before setting audio settings, no wonder I'm getting such broken, inconsistent behaviour. That sounds like incredibly broken, bad design, if it's the case, and should definitely be fixed.

Revision history for this message
Hui Wang (hui.wang) wrote :

What I saw is the hdmi-port0 (monitor) is resumed earlier than hdmi-port1 (home theatre) and hidmi-port0 has higher priority than hdmi-port1, so the profile of hdmi-port1 will not be active and the sink of hdmi-port1 will not be created after resume. (not 100% sure)

If you could not switch the port, we have another way to do the test. Drop the (load-module module-switch-on-connect blacklist=""), then edit the /usr/share/pulseaudio/alsa-mixer/paths/ hdmi-output-0.conf and hdmi-output-1.conf, change the priority in 0.conf to 58 and change the priority in 1.conf to 59, then reboot.

When you have time, could do a test and collect the log between suspend and resume.

Revision history for this message
Tessa (unit3) wrote :

Note that I made the changes you recommended in those files and had used it for a couple weeks, and it seemed to be behaving as expected. However after the update to 20.10, it seems to have reverted the changes and now my sound is broken again, experiencing even *worse* problems with puleaudio 1:13.99.2-1ubuntu1. Now, after resume from sleep, all audio devices except the internal SPDIF are missing, and never re-appear.

This begs a few questions: why is the priority order incorrect in those config files, and why does pule reset it to the wrong values on upgrade? what has changed in the newer pulse release that now it just messes up my sound even worse on 20.10 than it was on 20.04?

I'll re-instate the logging and attach a new log soon.

Revision history for this message
Tessa (unit3) wrote :

this is the log after resuming, where no audio devices are available post-resume except the internal SPDIF. so this bug has gotten significantly worse in the move from 20.04->20.10.

Tessa (unit3)
summary: - pulseaudio has is buggy with hdmi audio and sleep/wake
+ pulseaudio breaks hdmi audio on sleep/wake in ubuntu 20.10
Revision history for this message
Tessa (unit3) wrote : Re: pulseaudio breaks hdmi audio on sleep/wake in ubuntu 20.10

additional behaviour I've noticed:

on first boot, when the sound device isn't in use for a while, it stops sending bitstream data to the receiver, until there's a new audio event. it seems to be some sort of device sleep mode.

on 20.04, after resuming from sleep, this device sleep mode wouldn't activate again. on 20.10, it activates after sleep, but if it does, about half the time it breaks the sound output and i have `pulseaudio -k` to get things back to a usable state.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :
summary: - pulseaudio breaks hdmi audio on sleep/wake in ubuntu 20.10
+ Pulseaudio breaks HDMI audio on sleep/wake
tags: added: hdmi
Revision history for this message
Tom (dgenr8) wrote :

I have the same issue. On 20.04, pulse audio creates of the HDMI/DP device on wake after sleep, and starts using it even though I previously configured the earlier copy of itself to "Off" using pavucontrol.

This is particularly annoying because it the device is built into my monitor, is crappy, and there is no way to physically turn off the device.

Revision history for this message
Gustik (gustav-kutugutov) wrote :

I have the same issue.
Linux nova 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 20.04.1 LTS

Revision history for this message
Sergio S (sergiorcs82) wrote :

This bug affects me too.
Linux laptop 5.4.0-66-generic #74-Ubuntu SMP Wed Jan 27 22:54:38 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 20.04.2 LTS

I think this bug may (at least in some cases) be related to this here question: https://askubuntu.com/questions/1234807/no-sound-after-sleep-ubuntu-20-04 .

The solution they found involves removing the sound device and requesting a rescan:

echo 1 > /sys/bus/pci/devices/<device_address>/remove
echo 1 > /sys/bus/pci/rescan

They automated this through a script such as this one: https://github.com/GHopperMSK/configs/blob/master/bin/restart-sound

Revision history for this message
Tessa (unit3) wrote :

note that I've switched to using pipewire to replace pulse, and it doesn't have this problem. so this is definitely a pulse specific issue. thankfully pipewire is mature enough to use full time now, and I'd recommend folks experiencing this problem give it a shot, since it offers pulse, alsa, and jack protocol compatibility.

https://pipewire.org/

Revision history for this message
Le Gluon Du Net (legluondunet) wrote :

is this a pulseaudio bug ? If so where are reported the bug upstream, someone has a link?

Revision history for this message
Le Gluon Du Net (legluondunet) wrote :

This bug does no more happened since several weeks on my Ubuntu 20.04/Nvidia card GTX770

Revision history for this message
Brian Brunswick (brian-ithil) wrote :

This happens to me on a GTX1070 multiple monitor desktop machine with no need to suspend or sleep at all. Just locking the screen and unlocking resets the audio output device, and sometimes the input device.

Revision history for this message
SA (superaorta) wrote :

I have this bug _but_ it went away about two months ago after some updates but has returned with vengeance a couple of updates ago and after the latest updates (including kernel and pulseaudio) it's really borked.

Previously I'd have no sound until I did pulseaudio -k which would fix everything.

Now if I do this I _still_ have no audio until I run pavucontrol and reselect my sound device (which pavucontrol says is unavailable), then restart all my sound producing programs and, because the volume controls in KDE are broken, I have to restart plasmashell.

pulseaudio 1.13.99
kernel 5.4.0-77-generic

Happens everytime my computer sleeps.

Revision history for this message
Alexey Gusev (alexeygusev) wrote :

the same problem on 21.10
pulseaudio package 1:15.0+dfsg1-1ubuntu2

default output is reset in random order after resume from sleep. Sometimes it stays as it was before suspend, but more often it just changes to HDMI or dock output.

Revision history for this message
Igor V. Kovalenko (i-garrison) wrote :

I believe there is no defined order in which audio devices are resuming, which makes them appear to pulseaudio in random order. This is probably causing pulseaudio module-switch-on-connect to flip user preference to each appearing device in same (random) order. If you do not use this function you can disable module-switch-on-connect or use it's blacklist to prevent your preference flipping between devices.

Pulseaudio itself is not aware of suspend/resume function. I do not know if there is any system callback that confirms that system completed resume sequence and everything is back (including access rights to audio devices) so fixing this issue in full will be not a trivial task.

With pulseaudio-15.0 update you can tell pulseaudio to always select specified profile when device appears. This also is not a complete solution, but you can either make sure your HDMI is always off or is always using the profile with your preferred port:
https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/15.0/#cardprofilescanbesettosticky
Pavucontrol 5.0 has easy button for this, or use pactl send-message as described in release notes.

Revision history for this message
Hui Wang (hui.wang) wrote :

We have an OEM bug which is similar to this one. I don't know if it is the exact same issue as this one, to fix that issue, I did some change in the module-card-restore.c, and If users is on the ubuntu Linux 20.04, please try this testing-pulseaudio (try 2 hours later since the building process has not finished yet): https://launchpad.net/~hui.wang/+archive/ubuntu/pa-testing

steps:
rm ~/.config/pulse/*
sudo add-apt-repository ppa:hui.wang/pa-testing
sudo apt-get update
sudo apt install pulseaudio
reboot
start to test.

Revision history for this message
xinematik (xinematik) wrote :

I'm gonna try Hui Wang's patch because I'm having the same issue on a fresh install.

Revision history for this message
Robert Rongen (robertrongen) wrote :

Solved by executing amixer -q -D pulse sset Master toggle
https://askubuntu.com/a/1341471

Revision history for this message
Luca Pavan (anotherlucapavan) wrote (last edit ):

In my case, a simple pulseaudio -k on terminal fixes but surely I'd prefer a solution rather than having to apply this command.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.