Improve Volume Wheel Daemon (Bounty!)


I dit thought these Features where only available whit a Apple Device, but even the ANC works whit Pyra..
but the AirPods are quite open for non Apple Devices: there are Headphones out there that need an App so they don’t work on Pyra

Shure it’s nothing Professional Pyra Users would be exited but I never said im Professional ..
 
I think I can add fixes over the next 2-3 days and include them in letux-6.1-rc7.
Click to expand...

I'm close to some fixes (already improved threshold setting logic) - but unfortuantely I had to upgrade my build host and there is now some issue with the (new) gcc and (old) cross compiler toolchains so that I can not yet recompile the kernel and do further testing until I have fixed the compilers.

EDIT: compilers have been fixed.
 
Last edited:
First test results: threshold calculation seems to be improved, but driver reports -EBUSY after a while, when trying to set threshold values in the driver. May be related to calibration.
E.g.
Code: 
Failed to enable upper threshold 1149: -16
Failed to enable lower threshold 922: -16
 
The userspace daemon has received a couple of nice fixes from another helpful netizen :D I've been too busy myself to work on this lately, so your work is very appreciated @hns
 
Last edited:
Oooh, really nice seeing updates :D
Question is... who should get the bounty now.
Any ideas? Should we share it to anyone involved?
 
Just a short heads up that I'm not gonna have time to work on this for at least a couple more days. Maybe not until after Christmas. Quite swamped with other commitments right now.

EDIT: I'm still gonna poll the forums looking for the latest updates :D
 
Last edited:
Risca said:
that I'm not gonna have time to work on this for at least a couple more days. Maybe not until after Christmas. Quite swamped with other commitments right now.
Click to expand...
Same for me, unfortunately. And also no time for working on the AESS subsystem driver.

And I have seen a strange bug in the kernel driver (it stops accepting changes for the threshold values) which deserves more research.

Well, next year comes soon and will be long compared to the days left over from this month :)
 
hns said:
And I have seen a strange bug in the kernel driver (it stops accepting changes for the threshold values) which deserves more research.
Click to expand...
I think I've found the root cause of that bug: we both accept 0 as a valid threshold value and test thres != 0 to see if a channel is configured. Hence, if a threshold value is set to 0 we no longer detect the channel as configured :oops: I'm working on a fix now. Not sure which is best, though:
  • treat 0 as an invalid threshold value and return -EINVAL, or
  • treat 0 as a perfectly valid value and leave it up to userspace to not shoot itself in the foot.
The thing is, 0 makes sense for upper threshold but make little sense for lower thresholds. I'm leaning towards the latter, and fix the volume wheel daemon with this knowledge in mind. I even have a unittest for it already! :D
 
Okay, I think I have something that should be much more stable now. Two commits:
I'm working on some improvements to the userspace daemon. There is currently 1 outstanding issue when the volume wheel approaches the minimum value. Then a non-0 value can be reported and a threshold value set so low that it never triggers the ADC interrupt. Reading the ADC value manually will at this point show 0, so I'm thinking of implementing a small timer that gets reset every time the program is woken up by the kernel. If the timer triggers, read the value 1 more time and then disable the it. This would mean that every wakeup from the kernel will always trigger at most 1 more wakeup by the timer some time later. I think that would be okay :)
 
I tested out a timer and it did improve things, but I'm still able to reproduce the issue. I made some more changes and I believe I have a stable solution now:
  • if the calculated lower threshold level is below the configured minimum level, clamp the value to 0 and disable the threshold
  • change default minimum to 10 mV. Everything (both calculated threshold and ADC readings) below this level will get clamped to 0
  • check the value again after 200 ms to see if it changed. If not, stop the timer. Timeout value and timer enable/disable can be adjusted on the command line.
    I think the timer can actually be disabled and only use the workaround above :)
This appear to produce stable results on my devboard :D
Latest code available here: https://github.com/Risca/pyra_vol_mon
 
I spent some time today to learn GitHub actions and create a deb package for the userspace tool :D

Check out the first official release!
https://github.com/Risca/pyra_vol_mon/releases/tag/v1.0.1

The deb package should install without issues on the Pyra, but you need the kernel changes for it to be of any use.

Also, this package only provides the binary. Some more work is needed to integrate it with the Pyra
 
Okay, it looks like the necessary changes for this got accepted for upstream: https://marc.info/?l=linux-iio&m=168158308019708&w=2

If nothing major gets found during testing and review on the way, It looks like my patches will land in the next 6.4 release of the kernel! :D
This means that once the Pyra starts using Linux-6.4 or later, no custom patches are needed for my solution to the pyra volume wheel daemon!

I'm super excited that my changes got accepted :D
 
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
25K
matzesu
matzesu
NESnero
Two questions, mice support and Audio volume.
Replies
4
Views
990
NESnero
NESnero
Back
Top