reset sound after suspend to memory (deep sleep)
(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
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
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
(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):

  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
(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
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.
(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).

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.
(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).

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

Possibly Related Threads…
Thread Author Replies Views Last Post
  PineBook Pro seems to go to deep sleep, but doesn't wake up pogo 1 39 Yesterday, 08:27 AM
Last Post: wdt
  How to make manjaro sleep or hibernate? KDE? regretfulpineuser 0 220 06-20-2022, 12:56 AM
Last Post: regretfulpineuser
  Working suspend on Manjaro brzegorz 3 2,481 12-03-2021, 01:39 PM
Last Post: rik-shaw
  Sound stuttering on Manjaro gnome after latest kernel upgrade? pjsf 0 1,029 07-13-2021, 10:37 PM
Last Post: pjsf
Music No sound on PBP default installation ivek 9 5,323 05-09-2021, 05:58 PM
Last Post: binholz
Question Help: Pinebook Pro will not enter sleep [Manjaro 20.04] EverythingIsInput 49 44,226 05-07-2021, 06:21 AM
Last Post: line72
  Anyone can get deep sleep fully works with NVME rootfs? plumlis 0 1,341 01-11-2021, 09:58 AM
Last Post: plumlis
  Installing Ubuntu 20.04 (Focal) with BSP uBoot with deep sleep and sound Syonyk 17 12,489 11-19-2020, 03:16 AM
Last Post: FeMike
  Pinebook pro crashing when put to sleep?? [Manjaro] edward 13 8,846 11-17-2020, 07:17 AM
Last Post: ab1jx
Bug eMMC Fails After Suspend Lodj 3 2,507 11-16-2020, 11:06 PM
Last Post: ab1jx

Forum Jump:

Users browsing this thread: 1 Guest(s)