Bug 213793 - No input from internal mic after resuming from hibernate (renoir)
Summary: No input from internal mic after resuming from hibernate (renoir)
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-20 05:53 UTC by Carlos Pita
Modified: 2021-09-22 01:04 UTC (History)
1 user (show)

See Also:
Kernel Version: 5.12.16 5.13.1 5.14.rc1
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Attempt to fix the issue (1.01 KB, patch)
2021-07-20 18:32 UTC, Mario Limonciello (AMD)
Details | Diff

Description Carlos Pita 2021-07-20 05:53:45 UTC
After booting Linux with the PulseAudio server in a HP ENVY x360 13-AY0103LA (AMD Ryzen 3 4300U) I get a properly working internal mic. But after resuming the same working system from an otherwise successful hibernation, the internal mic is no longer feeding any signal. It doesn't seem to be a problem at the PulseAudio level, since the device is still there and backed by the right card and device, it just has no input signal. All other mics in the system (my webcam's, my BT speaker's and my USB headset's) are responsive after resuming, the internal one is the only failing one.

Output from inxi:
-----------------

Audio:     Device-1: AMD driver: snd_hda_intel 
           Device-2: AMD Raven/Raven2/FireFlight/Renoir Audio Processor driver: snd_rn_pci_acp3x 
           Device-3: AMD Family 17h HD Audio driver: snd_hda_intel 
           Device-4: Logitech HD Pro Webcam C920 type: USB driver: snd-usb-audio,uvcvideo 
           Device-5: Logitech Logitech USB Headset type: USB driver: hid-generic,snd-usb-audio,usbhid 

Output from arecord -l:
-----------------------

**** List of CAPTURE Hardware Devices ****
card 1: Generic_1 [HD-Audio Generic], device 0: ALC245 Analog [ALC245 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: acp [acp], device 0: DMIC capture dmic-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 3: C920 [HD Pro Webcam C920], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 4: Headset [Logitech USB Headset], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Versions:
---------

pulseaudio 14.2
alsa 1.2.5.1
kernel 5.12.16, 5.13.1, 5.14.rc1
Comment 1 Carlos Pita 2021-07-20 05:55:09 UTC
Notice that the failing mic is the one controlled by snd_rn_pci_acp3x.
Comment 2 Carlos Pita 2021-07-20 05:56:25 UTC
Also, here are some things I tried but didn't work:

* This is not a problem of “mic not working”. The mic works perfectly well until resuming from hibernation. I don’t need to set snd-rn-pci-acp3x dmic_acpi_check=1 at all for the mic to work and it doesn’t fix my problem anyway.

* Blacklisting snd-rn-pci-acp3x makes the mic useless from the beginning.

* It’s not a mixing problem. Capture is unmuted and at top volume.
Comment 3 Mario Limonciello (AMD) 2021-07-20 15:35:48 UTC
As an experiment, if you unload and reload snd-rn-pci-acp3x after hibernate, does that help?
Comment 4 Carlos Pita 2021-07-20 18:15:04 UTC
Yes, that helps. Indeed it was one of the first things I tried, but:

- rmmod complained about a busy device.
- rmmod -f kept running forever.

So, at the moment, I left that as yet another dead end. But now I figured out that the problem is that after doing `systemctl stop --user pulseaudio` or `pulseaudio -k` the server gets automatically restarted, so I did the following:

1. rmmod -f snd-rn-pci-acp3x &
2. pulseaudio -k
3. modprobe snd-rn-pci-acp3x &
4. pulseaudio -k

Otherwise steps 1 and 3 hang. As a workaround I would like to script this, but given the issues described above it would be nice to refine this 4-step procedure of unload-and-reload. Is there a cleaner and faster way to do it? Maybe I should stop the pulseaudio.socket first?
Comment 5 Mario Limonciello (AMD) 2021-07-20 18:32:15 UTC
Created attachment 297949 [details]
Attempt to fix the issue
Comment 7 Carlos Pita 2021-09-22 00:45:10 UTC
Mario, is this still open because you're waiting for me to test this?
Comment 8 Mario Limonciello (AMD) 2021-09-22 01:04:41 UTC
It's open because I don't have permissions to close it, either you or a maintainer for the subsystem will need to close it.

Note You need to log in before you can comment on or make changes to this bug.