Bug 1191247 - audio goes to mono after waking up from sleep
Summary: audio goes to mono after waking up from sleep
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Current
Hardware: 64bit openSUSE Tumbleweed
: P5 - None : Normal (vote)
Target Milestone: ---
Assignee: openSUSE Kernel Bugs
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-02 20:40 UTC by Andrea P
Modified: 2021-11-02 15:58 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
pre-sleep alsa.sh (112.81 KB, text/plain)
2021-10-04 17:43 UTC, Andrea P
Details
post-sleep alsa.sh (112.82 KB, text/plain)
2021-10-04 17:44 UTC, Andrea P
Details
rebooting usb module (70.68 KB, image/jpeg)
2021-10-04 17:46 UTC, Andrea P
Details
alsactl.out (35.60 KB, text/plain)
2021-10-23 12:19 UTC, Andrea P
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea P 2021-10-02 20:40:08 UTC
hey everybody.
I got this issue with regards to the audio coming from my USB sound card (Audient iD14): every time I put the pc on sleep and wake it up, every single source of audio goes to mono and I can hear the music/sounds coming just from one of my two speakers.
I did update to PipeWire, however the issue continues as it was with PulseAudio or Jack.
To fix that I can either plug my usb sound card off and plug back in or restart the pc.
Thanks.
Comment 1 Takashi Iwai 2021-10-03 07:52:12 UTC
I'm building a kernel with a backport from the upstream commit that might be relevant.  It's being built in OBS home:tiwai:bsc1191247 repo.  It'll be available later (after an hour or so) at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1191247/standard/
Please give it a try later.

Note that it's an unofficial build, hence it won't boot with Secure Boot.
Comment 2 Andrea P 2021-10-03 10:29:13 UTC
Hi! Thank you for your quick response.
I just tried your kernel but unfortunately it doesn't fix the audio issue.
Is there something I can log for you?
Thanks
Comment 3 Takashi Iwai 2021-10-03 14:52:23 UTC
Thanks for quick testing.

Then could you load alsa-info.sh output from the patched kernel after suspend/resume?  Run the script with --no-upload, and use Bugzilla attachment.

Also, for verifying whether it's a driver PM problem, try the following:

- Before and after suspend/resume, try to play without PA, PW or JACK but via ALSA native API, e.g.
   % aplay -Dplughw:XXX foo.wav
  where XXX is the card number like 0, 1, 2, corresponding to the device index appearing in /proc/asound/cards.

  I suppose this also results in the mono output?

- Get alsa-info.sh outputs before and after the suspend/resume.

- Check whether the problem persists with suspend-to-RAM and suspend-to-disk (hibernate).  I assume you're dealing with the former, right?

- Last but not least, check whether re-loading the driver fixes the problem without re-plugging.  You might need to go out of desktop session once, unload snd-usb-audio module and re-load snd-usb-audio module on Linux console.
Comment 4 Andrea P 2021-10-03 17:37:27 UTC
(In reply to Takashi Iwai from comment #3)
> Thanks for quick testing.
> 
> Then could you load alsa-info.sh output from the patched kernel after
> suspend/resume?  Run the script with --no-upload, and use Bugzilla
> attachment.

Thank  you. 
Sorry but I have no idea how to run this script. where is located? so sorry, I'm not that expert :D
 
> Also, for verifying whether it's a driver PM problem, try the following:
> 
> - Before and after suspend/resume, try to play without PA, PW or JACK but
> via ALSA native API, e.g.
>    % aplay -Dplughw:XXX foo.wav
>   where XXX is the card number like 0, 1, 2, corresponding to the device
> index appearing in /proc/asound/cards.
> 
>   I suppose this also results in the mono output?

Yes indeed. It does sound as mono after waking up from sleep

> 
> - Check whether the problem persists with suspend-to-RAM and suspend-to-disk
> (hibernate).  I assume you're dealing with the former, right?

Hibernate it doesn't work on my PC (maybe because I don't have a swap partition?).

> 
> - Last but not least, check whether re-loading the driver fixes the problem
> without re-plugging.  You might need to go out of desktop session once,
> unload snd-usb-audio module and re-load snd-usb-audio module on Linux
> console.

Again, so sorry but I don't know how to stop and re-load this module.
Comment 5 Takashi Iwai 2021-10-04 12:00:00 UTC
(In reply to Andrea P from comment #4)
> (In reply to Takashi Iwai from comment #3)
> > Thanks for quick testing.
> > 
> > Then could you load alsa-info.sh output from the patched kernel after
> > suspend/resume?  Run the script with --no-upload, and use Bugzilla
> > attachment.
> 
> Thank  you. 
> Sorry but I have no idea how to run this script. where is located? so sorry,
> I'm not that expert :D

It's /usr/sbin/alsa-info.sh included in alsa-utils package.  It should have been already installed.  Just run it as root with --no-upload option, and attach the generated file to Bugzilla (don't paste, it's big).


> > 
> > - Check whether the problem persists with suspend-to-RAM and suspend-to-disk
> > (hibernate).  I assume you're dealing with the former, right?
> 
> Hibernate it doesn't work on my PC (maybe because I don't have a swap
> partition?).

Right, hibernate works only with a swap (or other dedicated) partition.

> > - Last but not least, check whether re-loading the driver fixes the problem
> > without re-plugging.  You might need to go out of desktop session once,
> > unload snd-usb-audio module and re-load snd-usb-audio module on Linux
> > console.
> 
> Again, so sorry but I don't know how to stop and re-load this module.

OK, then to make things easier:
- Try to boot with a boot option "3"
  This will boot to Linux console without GUI
- Login there, plug USB-audio device, test directly via aplay
    % aplay -Dplughw:XXX foo.wav
  as mentioned in the above.
- Do suspend/resume
    % systemctl suspend
- Check again aplay and confirm the mono output
- Unload / reload the module
    % sudo modprobe -r snd-usb-audio
    % sudo modprobe snd-usb-audio
- Test aplay again
Comment 6 Andrea P 2021-10-04 17:43:45 UTC
Created attachment 852919 [details]
pre-sleep alsa.sh
Comment 7 Andrea P 2021-10-04 17:44:54 UTC
Created attachment 852921 [details]
post-sleep alsa.sh
Comment 8 Andrea P 2021-10-04 17:46:35 UTC
Created attachment 852922 [details]
rebooting usb module
Comment 9 Andrea P 2021-10-04 17:49:23 UTC
I finally made it, thanks :)

> 
> It's /usr/sbin/alsa-info.sh included in alsa-utils package.  It should have
> been already installed.  Just run it as root with --no-upload option, and
> attach the generated file to Bugzilla (don't paste, it's big).
> 

Done, I've attached both pre-sleep and post-sleep alsa-info.sh output

> 
> OK, then to make things easier:
> - Try to boot with a boot option "3"
>   This will boot to Linux console without GUI
> - Login there, plug USB-audio device, test directly via aplay
>     % aplay -Dplughw:XXX foo.wav
>   as mentioned in the above.
> - Do suspend/resume
>     % systemctl suspend
> - Check again aplay and confirm the mono output
> - Unload / reload the module
>     % sudo modprobe -r snd-usb-audio
>     % sudo modprobe snd-usb-audio
> - Test aplay again

done, I can confirm it sound in mono. Once I try to reboot the usb module, it gives me "Device or resource busy". Please see screenshot attached "rebooting usb module".
Thanks!
Comment 10 Takashi Iwai 2021-10-05 07:23:50 UTC
(In reply to Andrea P from comment #9)
> > OK, then to make things easier:
> > - Try to boot with a boot option "3"
> >   This will boot to Linux console without GUI
> > - Login there, plug USB-audio device, test directly via aplay
> >     % aplay -Dplughw:XXX foo.wav
> >   as mentioned in the above.
> > - Do suspend/resume
> >     % systemctl suspend
> > - Check again aplay and confirm the mono output
> > - Unload / reload the module
> >     % sudo modprobe -r snd-usb-audio
> >     % sudo modprobe snd-usb-audio
> > - Test aplay again
> 
> done, I can confirm it sound in mono. Once I try to reboot the usb module,
> it gives me "Device or resource busy". Please see screenshot attached
> "rebooting usb module".
> Thanks!

Unloading the module is with modprobe -r, not with -f.
But I guess pulseaudio or pipewire is running even on Linux console, which  would blocks the operation in anyway.  Hm.

Maybe you can login as root and test in the same way.  If it still gives a resource busy error, try to run like:
  fuser -k /dev/snd/*
then run the command (aplay or modprobe).
Comment 11 Takashi Iwai 2021-10-05 07:25:44 UTC
Oh, and now I see you have Audient device in the card 0, judging from alsa-info.sh output.  In that case, test is like
  aplay -Dplughw:0 somefile.wav

The card index varies dynamically, so please check the output of "cat /proc/asound/cards" beforehand.
Comment 12 Andrea P 2021-10-05 21:51:44 UTC
(In reply to Takashi Iwai from comment #11)
> Oh, and now I see you have Audient device in the card 0, judging from
> alsa-info.sh output.  In that case, test is like
>   aplay -Dplughw:0 somefile.wav
> 
> The card index varies dynamically, so please check the output of "cat
> /proc/asound/cards" beforehand.

here I am!
so, long story short: it doesn't matter what I do, after suspend the audio goes mono.

In any single attempt I've checked if my sound card index was correct and it was.
I tried to login as root and restart the usb module and as a matter of fact, it works straight away. so no "device or resource busy" anymore, but still, once I restart it the audio is still in mono.

No idea if pulseaudio/pipewire still works even on Linux console, sorry.

What else can I do for you?

Thanks.
Comment 13 Takashi Iwai 2021-10-11 08:33:15 UTC
The next step is try to adjust the mixer values manually after suspend/resume and see whether it influences on the behavior.

Unfortunately the alsactl contents are empty in alsa-info.sh outputs by some reason.  Could you run the following as root, and attach to Bugzilla?

  alsactl -f /tmp/alsactl.out store
Comment 14 Andrea P 2021-10-18 21:03:48 UTC
(In reply to Takashi Iwai from comment #13)
> The next step is try to adjust the mixer values manually after
> suspend/resume and see whether it influences on the behavior.
> 
> Unfortunately the alsactl contents are empty in alsa-info.sh outputs by some
> reason.  Could you run the following as root, and attach to Bugzilla?
> 
>   alsactl -f /tmp/alsactl.out store

Hi!, sorry I've been abroad and I couldn't do anything.

> Could you run the following as root, and attach to Bugzilla?
> 
>   alsactl -f /tmp/alsactl.out store

Running the command as root it doesn't give me anything to upload. I just got:

alsactl: get_control:255: Cannot read control '2,0,0,Input Gain Control,0': Broken pipe
Comment 15 Andrea P 2021-10-18 21:06:07 UTC
I forgot to point out that I'm also trying MicroOS with Pipewire and DE GNOME (if that's changes anything) and the issue is NOT happening for some reason. I can put on sleep and resume the machine and the audio works in stereo just fine.
Comment 16 Takashi Iwai 2021-10-19 05:50:14 UTC
Aha, that's an error about the mixer, and it might be relevant.

Then please create a file /etc/modprobe.d/60-usb-audio.conf containing the following line:

options snd-usb-audio ignore_ctl_error=1

And retest with the would-be-broken system.  This should ignore such an error.
Comment 17 Takashi Iwai 2021-10-19 07:46:17 UTC
And if the option above helps, please try the kernel again in the URL mentioned in comment 1.  It was rebuilt with a new patch.
Don't forget to drop the modprobe.d stuff you've added for the previous test before trying it out.
Comment 18 Andrea P 2021-10-19 17:44:56 UTC
Hi! Something happened, however I can't tell exactly if before or after I've created 60-usb-audio.conf.

The audio now works fine, however the volume of the right channel is slightly below the left channel. This is now happening all the time: before the sleep, after the sleep, after a fresh restart, after unplug and plug back the audio device. Every Single Time.

Tried your kernel as well and it doesn't seems to change much. The right channel is always lower then the left channel.

Tried to delete 60-usb-audio.conf, it doesn't change anything.

To avoid any doubt, I restarted on macOS (which is in dual boot on the same machine), the audio is exactly the same for left and right channel. No differences.
Comment 19 Andrea P 2021-10-23 12:19:16 UTC
(In reply to Takashi Iwai from comment #13)
> The next step is try to adjust the mixer values manually after
> suspend/resume and see whether it influences on the behavior.
> 
> Unfortunately the alsactl contents are empty in alsa-info.sh outputs by some
> reason.  Could you run the following as root, and attach to Bugzilla?
> 
>   alsactl -f /tmp/alsactl.out store

Hi, I forgot to attach the alsactl.out I was able to generate after creating 60-usb-audio.conf

Hopefully it will says why my right channel is lower in volume.
Comment 20 Andrea P 2021-10-23 12:19:52 UTC
Created attachment 853327 [details]
alsactl.out
Comment 21 Andrea P 2021-10-28 16:04:53 UTC
Hi, I'm pleased to say this has now been fixed. Not sure what did happen to get it fixed, but the most important thing is that it's not happening anymore.
Thanks for your help!
Comment 22 Takashi Iwai 2021-11-02 15:58:55 UTC
OK, then let's close.  Feel free to reopen if you encounter the same problem again.