+- PINE64 (https://forum.pine64.org)
+-- Forum: Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=111)
+--- Forum: Linux on Pinebook Pro (https://forum.pine64.org/forumdisplay.php?fid=114)
+--- Thread: reset sound after suspend to memory (deep sleep) (/showthread.php?tid=10268)
Pages:
1
2
RE: reset sound after suspend to memory (deep sleep) - moonwalkers - 08-28-2021
(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
and installed the above mentioned kernel via packages linux-pinebookpro (-headers), edited /etc/systemd/sleep.conf with "SuspendState=mem.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
If I use your script and systemd-unit unchanged, system hangs on waking up from sleep.
If I use the command
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.Code:sudo tee /sys/bus/i2c/drivers/es8316/{un,}bind <<< 1-0011 > /dev/null
Which sound server do you use, if any?
RE: reset sound after suspend to memory (deep sleep) - JGkn - 08-29-2021
(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
RE: reset sound after suspend to memory (deep sleep) - moonwalkers - 08-29-2021
(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.
RE: reset sound after suspend to memory (deep sleep) - JGkn - 08-30-2021
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.
RE: reset sound after suspend to memory (deep sleep) - JGkn - 09-10-2021
(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.
RE: reset sound after suspend to memory (deep sleep) - JGkn - 09-21-2021
(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/packages/core/linux-pinebookpro ?
RE: reset sound after suspend to memory (deep sleep) - Syonyk - 10-18-2021
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.