Improve Volume Wheel Daemon (Bounty!)


matzesu

Forum Addict!
Staff member
Joined
Oct 24, 2008
Messages
12,682
Age
38
Location
Germany,, Saarland, at home
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 ..
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
637
Location
Oberhaching
I think I can add fixes over the next 2-3 days and include them in letux-6.1-rc7.

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:

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
637
Location
Oberhaching
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
 

Risca

Very Active Member
Joined
Sep 25, 2011
Messages
110
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
 

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
637
Location
Oberhaching
Last edited:

EvilDragon

Administrator
Staff member
Joined
Mar 4, 2003
Messages
29,923
Age
45
Location
Ingolstadt
Oooh, really nice seeing updates :D
Question is... who should get the bounty now.
Any ideas? Should we share it to anyone involved?
 

Risca

Very Active Member
Joined
Sep 25, 2011
Messages
110
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:

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
637
Location
Oberhaching
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.
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 :)
 

Risca

Very Active Member
Joined
Sep 25, 2011
Messages
110
And I have seen a strange bug in the kernel driver (it stops accepting changes for the threshold values) which deserves more research.
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
 

Risca

Very Active Member
Joined
Sep 25, 2011
Messages
110
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 :)
 

Risca

Very Active Member
Joined
Sep 25, 2011
Messages
110
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
 
Top