Improve Volume Wheel Daemon (Bounty!)


elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,743
So youre hoping to improve things by making them more complicated?
This plan makes no sense whatsoever.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
15,853
Location
Somewhere off the coast of the EU
I'm not sure using the M4 cores will reduce usage of the A15 cores significantly enough to be bothered with. Unless the M4 cores are actually powered up at present and just spinning in an idle loop, actually using them for something might be better, but I'd have thought they'd be powered down in some way if not used.

But luckily, if you come up with a solution that works on the A15 then it should be a matter of recompiling it for thumb2 and then finding a way to upload it and run it on the M4 cores having a low power but responsive solution should work for both targets normally.
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
I've been tinkering with a different solution to this issue in in another thread.

It uses the builtin threshold feature of the palmas gpadc chipset which only wakes up the Cortex-A15 when the volume wheel moves. It requires an updated kernel driver which is already on its way into the Letux kernels and a userspace "daemon". This daemon:
  1. listens for events from the kernel that the volume wheel has moved
  2. reads the current value
  3. sets new thresholds
  4. calls an external, configurable executable with the current value. This allow for any user to use their own favorite sound system. I've just been using echo for testing :D
  5. go back to 1.
I think this approach can reach the lowest possible power consumption since nothing is running as long as the volume wheel doesn't move, which should be most of the time.

EDIT:
Sources:
 
Last edited:

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,743
I think this approach can reach the lowest possible power consumption since nothing is running as long as the volume wheel doesn't move, which should be most of the time.
There is still a chip that would need to check on the wheel, the best possible chip for the task, but that should still consume power.
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
624
Location
Oberhaching
There is still a chip that would need to check on the wheel, the best possible chip for the task, but that should still consume power.
Yes, it is the power controller chip which also monitors battery, charger plug-in etc. with the same circuit (just on a different channel). But that is far from being as power hungry as the M4 or A15 cores running background tasks.
So kudos to risca for finding the palmas gpadc threshold feature and providing us with working code!
BTW: the latest daemon will now be integrated into the LetuxOS rootfs.
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
Yes, it is the power controller chip which also monitors battery, charger plug-in etc. with the same circuit (just on a different channel). But that is far from being as power hungry as the M4 or A15 cores running background tasks.
So kudos to risca for finding the palmas gpadc threshold feature and providing us with working code!
BTW: the latest daemon will now be integrated into the LetuxOS rootfs.
Yes, exactly. That chip is already always on
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
250
I gave it a try,

First i applied the patches to the 5.6.19 kernel (since that's still the only one where everything (3d,screen,audio) works properly)
Patch applied with a few tweaks, but i assume some more parts of the palmas_gpadc driver outside the iio got changed since that kernel.
No values were read from the device.

on kernel letux-6.1.0-rc5:
iio device returns values, pyra_vol_mon works, but only reports values between 6 and 1249.
(just running it with "sudo ./pyra_vol_mon echo"
Reading the raw iio device with my own daemon does show the expected 0-2050 raw values, so it's probably something in the vol_mon

When the value is at minimum (6, but also happens if you manage to get it on anything <10) it triggers outputs continously, even if the value doesn't change.

To make things even more fun, the L15 audio device doesn't appear (only hdmi), so that kernel isn't usable for us. (on top of the other issues)
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
624
Location
Oberhaching
I gave it a try,

First i applied the patches to the 5.6.19 kernel (since that's still the only one where everything (3d,screen,audio) works properly)
Patch applied with a few tweaks, but i assume some more parts of the palmas_gpadc driver outside the iio got changed since that kernel.
No values were read from the device.

on kernel letux-6.1.0-rc5:
iio device returns values, pyra_vol_mon works, but only reports values between 6 and 1249.
(just running it with "sudo ./pyra_vol_mon echo"
Reading the raw iio device with my own daemon does show the expected 0-2050 raw values, so it's probably something in the vol_mon

When the value is at minimum (6, but also happens if you manage to get it on anything <10) it triggers outputs continously, even if the value doesn't change.

To make things even more fun, the L15 audio device doesn't appear (only hdmi), so that kernel isn't usable for us. (on top of the other issues)
Well, -rc (or "Prepatch") kernels are never "useable" since they are development and integration snapshots and Letux can't be better than Linus... See: https://www.kernel.org/category/releases.html
But v6.1 will likely become the next longterm kernel with long-lasting upstream support which means plenty of chances to iron out Letux specific issues.
So far, letux-6.1-rc5 still provides the old pyra_vol_mon. The latest changes by risca to give 0 values properly are scheduled to become available with -rc6 in the next days.
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
250
Yes, I kind of rushed that post a bit, I should have added something like "Can this be backported to one of the kernels that's in a usable state" at the end there.
Since you said it was integrated into LetuxOS, I assumed the driver+daemon was fully working, but I might have read that a bit too optimistic.
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
I gave it a try,
Great!
First i applied the patches to the 5.6.19 kernel (since that's still the only one where everything (3d,screen,audio) works properly)
Patch applied with a few tweaks, but i assume some more parts of the palmas_gpadc driver outside the iio got changed since that kernel.
No values were read from the device.
I'll have a look and see if I can reproduce the issue. Is this Letux-5.6.19 kernel or mainline? I'm gonna assume Letux-5.6.19 and pyra_defconfig :)
on kernel letux-6.1.0-rc5:
iio device returns values, pyra_vol_mon works, but only reports values between 6 and 1249.
(just running it with "sudo ./pyra_vol_mon echo"
Reading the raw iio device with my own daemon does show the expected 0-2050 raw values, so it's probably something in the vol_mon
There are 2 sysfs/iio files to read data from:
* in_voltage1_raw
* in_voltage1_input

The first one will give you the raw ADC values directly from the palmas chip. The latter one take the raw values and apply calibration data stored in the chip from the factory, and should convert the raw values to actual mV although I haven't verified it. This one should anyhow be more consistent across many Pyras because of the factory calibration data taken from the palmas chip.
When the value is at minimum (6, but also happens if you manage to get it on anything <10) it triggers outputs continously, even if the value doesn't change.
Yes, this has been addressed in the latest revisions: https://github.com/Risca/pyra_vol_mon/
Please let me know if it's still an issue :)
 
Last edited:

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
250
Great!

I'll have a look and see if I can reproduce the issue. Is this Letux-5.6.19 kernel or mainline?

It's Letux-5.6.19 with a few additional patches and a more debian compatible config. (We need aufs patched in for the dbp system, and the Letux config is very minimal)
It was scraped together from various git repos, but never really properly commited anywhere.

Exact source is here : https://packages.pyra-handheld.com/...-aufs_5.6.19-daveiii-pyradef-aufs.orig.tar.gz , with https://packages.pyra-handheld.com/...ef-aufs_5.6.19-daveiii-pyradef-aufs-3.diff.gz applied on top.
But if you can get it going in any of the letux-5.6.y kernels I'm sure I can get it going in ours.

If that fails, 5.10.y is a close second to being fully working, although that has an issue where the screen doesn't power back up after going into power/screensave mode.
Unfortunately anything after that, the gpu drivers either don't work at all, or give very low framerates. (with various amounts of breakage in other places too).
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
It's Letux-5.6.19 with a few additional patches and a more debian compatible config. (We need aufs patched in for the dbp system, and the Letux config is very minimal)
It was scraped together from various git repos, but never really properly commited anywhere.
Hmm... I can't get this kernel to boot on my devboard :( might be missing a cmdline parameter?
Exact source is here : https://packages.pyra-handheld.com/...-aufs_5.6.19-daveiii-pyradef-aufs.orig.tar.gz , with https://packages.pyra-handheld.com/...ef-aufs_5.6.19-daveiii-pyradef-aufs-3.diff.gz applied on top.
But if you can get it going in any of the letux-5.6.y kernels I'm sure I can get it going in ours.
I'll give this one a try
If that fails, 5.10.y is a close second to being fully working, although that has an issue where the screen doesn't power back up after going into power/screensave mode.
Unfortunately anything after that, the gpu drivers either don't work at all, or give very low framerates. (with various amounts of breakage in other places too).
Then maybe try this one :D
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
First i applied the patches to the 5.6.19 kernel (since that's still the only one where everything (3d,screen,audio) works properly)
Patch applied with a few tweaks, but i assume some more parts of the palmas_gpadc driver outside the iio got changed since that kernel.
No values were read from the device.
I'm able to reproduce the issue and I'll take a look when I get the time :)
 
  • Like
Reactions: rSl

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
250
Yup, works.
Still get the 6..1249 range thing though, (and continous output on 6) with most recent (last commit was 3 days ago) pyra_vol_mon from that repo.

Did you ever figure out why reading the adc is so incredibly slow/cpu heavy ? All the other iio devices seem to have none of the issues and report much faster at much lower cpu usage.
 

Risca

Active Member
Joined
Sep 25, 2011
Messages
92
Yup, works.
Still get the 6..1249 range thing though, (and continous output on 6) with most recent (last commit was 3 days ago) pyra_vol_mon from that repo.
Hmm... I have a couple of ideas, but I'm quite busy this week. You could try the --min flag to clamp the minimum value to e.g. 10 or something.
Did you ever figure out why reading the adc is so incredibly slow/cpu heavy ? All the other iio devices seem to have none of the issues and report much faster at much lower cpu usage.
I sometimes notice that the very first reading is slow/times out, but subsequent reads are much, much faster. How slow are we talking about here?
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
624
Location
Oberhaching
Have been testing a little.
1. well, values reported are 0..1250 (converted to mV by the calibration functions) but MAX value default is 2500. So why do we need min and max at all, if the value is the measured mV range (which is known to be based on the adc reference voltage of 1.2V and will not change)?
Ok, to make the pyra_vol_mon more universal. But we should then call it with -u 1200.
Anyways, it does not seem to be necessary to pass the lower and upper limits to the subprocess as they are system constants for each use (some script calling pyra_vol_mon should know and the script called from pyra_vol_mon).
2. sometimes there are many threshold reports if the wheel is almost 0.
3. the value 0 is reported but only if I move the wheel slowly enough towards 0.
4. If I send the pyra_volmon incl. its dependent subprocess to the background
Code:
/root/pyra_vol_mon/pyra_vol_mon -c 2 echo &
each call leaves a defunct subprocess. So the pyra_vol_mon should do a
Code:
wait(&status);
for the subprocess to complete.
5. I am thinking of using an udev rule to start the daemon if both, palmas-gpadc and sound card are available. This being a kernel feature may be more universal than requiring systemd. And make sure the daemon is started not before everything is in place.
I think I can add fixes over the next 2-3 days and include them in letux-6.1-rc7.
 
Last edited:

matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
12,607
Age
38
Location
Germany,, Saarland, at home
Im still impressed that the Pyra even supports the Touch Volume Controll from the Airpods Pro 2 ^^ but if its helps improving the Pyra for peaple that dont use the newest Apple Headphones, its quite wellcome, and i aprociate the work quite well,

HNS: Ichich bedanke mich herzlichst für deinen unermütlichen Einsatz für die Pyra^^
 
  • Like
Reactions: rSl
Top