reset sound after suspend to memory (deep sleep)
#11
(08-28-2021, 03:18 AM)JGkn Wrote:
(03-10-2021, 11:31 PM)moonwalkers Wrote: K, with some more modifications I was able to get the script working pretty well with sleep/resume cycles, with only caveat being applications that use sound may either quit/crash or lose sound until restart, or just pause playback - the exact behavior depends on a particular app. Here is the updated script:

Perhaps you can help me or give some hints - I can't get your solution to work.
I am on Kernel 5.7.19-1-MANJARO-ARM, coming from an installation with manjaro-arm-installer (encrypted) last week, then did
Code:
pacman -S uboot-pinebookpro-bsp
dd if=/boot/idbloader.img of=/dev/mmcblk2 seek=64 conv=notrunc
dd if=/boot/uboot.img of=/dev/mmcblk2 seek=16384 conv=notrunc
dd if=/boot/trust.img of=/dev/mmcblk2 seek=24576 conv=notrunc
and installed the above mentioned kernel via packages linux-pinebookpro (-headers), edited /etc/systemd/sleep.conf with "SuspendState=mem.

If I use your script and systemd-unit unchanged, system hangs on waking up from sleep.

If I use the command
Code:
sudo tee /sys/bus/i2c/drivers/es8316/{un,}bind <<< 1-0011 > /dev/null
directly in terminal or the echo-command for unbind in the newer script, system hangs, too (seems to start a process, that does not end and can't be aborted by strg-c.

Which sound server do you use, if any?
This message was created with 100% recycled electrons
  Reply
#12
(08-28-2021, 03:35 PM)moonwalkers Wrote: Which sound server do you use, if any?
Thanks for asking!

At first, I wanted to add, that the tee.../echo...-commands from your scripts not only start the hanging (?) process:
The unbind seems to work, because the tray icon/applet shows "no sound device detected" (translated from german) after command.

After that, your bind-command (e.g. from a different terminal) does not work. Error message would be something like "write error: no matching device found" (transl.).

Regarding Sound Server (partial output of inxi -Fazy):

Audio:
  Device-1: simple-audio-card driver: asoc_simple_card bus-ID: N/A
  chip-ID: simple-audio-card:es8316-sound class-ID: es8316-sound
  Device-2: simple-audio-card driver: N/A bus-ID: N/A
  chip-ID: simple-audio-card:hdmi-sound class-ID: hdmi-sound
  Sound Server-1: ALSA v: k5.7.19-1-MANJARO-ARM running: yes
  Sound Server-2: JACK v: 1.9.19 running: no
  Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.33 running: yes
  Reply
#13
(08-29-2021, 12:46 PM)JGkn Wrote:   Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.33 running: yes

K, that's probably where the problem lies - my script is geared towards PulseAudio and does not have any provisions for PipeWire. The core idea of the script is to first make the permissions on the audio device such that no new process can open it, then stop all the existing processes (which on a system using PulseAudio should be only the PulseAudio user session instance), then do the bind/unbind, and then restart the audio server. I haven't yet played with PipeWire--PulseAudio works well enough for my needs that I don't feel like fiddling with a less mature option, even if theoretically superior--so I cannot give you ready-to-go solution. You'll have to figure out yourself how to make sure PipeWire doesn't use the sound card while the driver is being rebound. But my guess is you might be able to simply replace the pulseaudio.s(ervice|ocket) with the equivalent PipeWire systemd units, assuming they still run in user session context and not system-wide context. If they run in system-wide context you should be able to get rid of all the dbus-related shenanigans.
This message was created with 100% recycled electrons
  Reply
#14
Thanks a lot. I will try to manage that.
Or get rid of pipewire, I don't think, I need it. But that doesn't seem to be easy, because it comes out of the box with Manjaro 21.8.
  Reply
#15
(08-29-2021, 10:32 PM)moonwalkers Wrote: K, that's probably where the problem lies - my script is geared towards PulseAudio and does not have any provisions for PipeWire. [...]

I tried it out now. Unfortunately there is no success for me.

As far as I (with my limited experience) can see, the pipewire-services still run in user-context, so I am able to stop them with
DBUS_SESSION_BUS_ADDRESS="$bus_addr" sudo -u $user -E /bin/systemctl --user stop pipewire*
in an adapted script or directly from terminal.
This makes the sound tray-icon crossed out.

The output of
lsof /dev/snd
is emtpy (if I do the chmod 000 /dev/snd/pcm...* or not).

But
echo "1-0011" > /sys/bus/i2c/drivers/es8316/unbind
always gives me an
Speicherzugriffsfehler (Speicherabzug geschrieben) = Memory access error (memory dump written)
no matter if called via script or directly in terminal.

It is not possible to do the bind-command after that.
(sudo echo "1-0011" > /sys/bus/i2c/drivers/es8316/bind
from usercontext makes "no permission" and 
sudo -s
echo "1-0011" > /sys/bus/i2c/drivers/es8316/bind
puts out "echo: Write error: No matching device found"

Maybe something changed behind the scenes since you made your script..?
Thanks for your help anyway.
  Reply
#16
(03-11-2021, 08:12 PM)Syonyk Wrote: Sorry... life got in the way.  I really should get that set of patches bundled up for submission, I just haven't been liking computers much lately and have been avoiding them as much as possible outside work.

My set of patches isn't very good, I'm certain it's not entirely correct. but it does work (mostly).



Code:
diff --git a/sound/soc/codecs/es8316.c b/sound/soc/codecs/es8316.c
[...]

When you write "but it does work (mostly)", may I ask about how to apply your set of patches?
(I am asking from a very unexperienced perspective...)
Do you think, the above patches are still up to date? I understand I would have to compile it into a self compiled kernel, right? Which one did/do you use?
The linux-pinebookpro kernel according to https://gitlab.manjaro.org/manjaro-arm/p...inebookpro ?
  Reply
#17
I suppose I should really, really get those cleaned up and submitted upstream. Too much life, too little time.

It's a standard kernel patch, you should be able to apply it, but it might not apply to the latest kernel revisions without some tweaks.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Sleep and external display - Are there any options? chris88233 7 1,482 09-04-2023, 09:03 PM
Last Post: wdt
  PineBook Pro seems to go to deep sleep, but doesn't wake up pogo 11 4,924 08-31-2023, 04:20 PM
Last Post: TRS-80
  Rkvdec memory leak? Abhinav 2 755 06-02-2023, 08:55 AM
Last Post: Abhinav
  Sound on Armbian Bram 1 818 04-01-2023, 03:16 PM
Last Post: TRS-80
  Suspend/Resume Broken with Bootloader on SPI Flash xp19375 2 1,086 03-24-2023, 04:25 PM
Last Post: srs5694
  With the help of a friend, I installed a beautiful deep os distribution, but I won't wangyukunshan 0 562 03-03-2023, 10:56 PM
Last Post: wangyukunshan
  Hibernation and Speaker Sound Issues, First Month of PBP kebab 7 2,798 11-02-2022, 02:33 PM
Last Post: kebab
  Resume from suspend not working after flashing Tow-Boot to SPI xp19375 3 1,861 10-31-2022, 10:14 AM
Last Post: wdt
  Loud distorted speaker sound when connecting to power supply myself600 2 1,121 09-21-2022, 12:11 PM
Last Post: myself600
  How to make manjaro sleep or hibernate? KDE? regretfulpineuser 0 935 06-20-2022, 12:56 AM
Last Post: regretfulpineuser

Forum Jump:


Users browsing this thread: 1 Guest(s)