Improve Volume Wheel Daemon (Bounty!)


So youre hoping to improve things by making them more complicated?
This plan makes no sense whatsoever.
 
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.
 
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:
Risca said:
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.
Click to expand...
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.
 
elw3 said:
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.
Click to expand...
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.
 
hns said:
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.
Click to expand...
Yes, exactly. That chip is already always on
 
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)
 
aTc said:
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)
Click to expand...
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.
 
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.
 
aTc said:
I gave it a try,
Click to expand...
Great!
aTc said:
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.
Click to expand...
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 :)
aTc said:
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
Click to expand...
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.
aTc said:
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.
Click to expand...
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:
Risca said:
Great!

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

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).
 
aTc said:
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.
Click to expand...
Hmm... I can't get this kernel to boot on my devboard :( might be missing a cmdline parameter?
aTc said:
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.
Click to expand...
I'll give this one a try
aTc said:
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).
Click to expand...
Then maybe try this one :D
 
aTc said:
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.
Click to expand...
I'm able to reproduce the issue and I'll take a look when I get the time :)
 
  • Like
Reactions: rSl
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.
 
aTc said:
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.
Click to expand...
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.
aTc said:
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.
Click to expand...
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?
 
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:
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
You must log in or register to reply here.

Similar threads

P
Squashed wifi antenna; volume wheel solder check
Replies
9
Views
4K
Lobo
Lobo
Michoko
Low volume output only on left side
Replies
3
Views
3K
darfgarf
darfgarf
D
  • Poll
Pandora Volume Control Method
Replies
16
Views
4K
Eolair
Eolair
Wally
  • Sticky
Current State of the Pyra
2 3 4
Replies
78
Views
26K
matzesu
matzesu
NESnero
Two questions, mice support and Audio volume.
Replies
4
Views
1K
NESnero
NESnero
Back
Top