Improve Volume Wheel Daemon (Bounty!)


Risca

Still Fresh
Joined
Sep 25, 2011
Messages
14
Are you volunteering to fix the kernel read?
It sounds really, really tempting :)unfortunately I don't have any Pyra hardware, free time, or even a working laptop at the moment :( I managed to brick my BIOS earlier this week and fixing that is currently my top priority.

Do we know if this bug exist on any other hardware? Like a raspberry pi, nanopi, C.H.I.P., or even an old BeagleBoard?
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,019
It sounds really, really tempting :)unfortunately I don't have any Pyra hardware, free time, or even a working laptop at the moment :( I managed to brick my BIOS earlier this week and fixing that is currently my top priority.

Do we know if this bug exist on any other hardware? Like a raspberry pi, nanopi, C.H.I.P., or even an old BeagleBoard?
Other devices are smart enough to not do it the way we ended up designing it...
 

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,583
There are pros and cons to every design.
This one will at least use no power when not in use.
How much power will an decoder wheel consume? Could we turn that off?
 

TrashyMG

Sarcasm Dispenser
Staff member
Joined
Jan 18, 2010
Messages
11,019
There are pros and cons to every design.
This one will at least use no power when not in use.
How much power will an decoder wheel consume? Could we turn that off?
It's an encoder wheel, I suspect the power consumption would be considerable less than polling an ADC on an interval as the wheel itself would trigger the change event. Also I wasn't implying that an Encoder wheel should have been the solution. During the original forum discussions, I was pushing something similar to the Pandora audio system honestly, it's simplistic and the audio quality was great on the Pandora.
 
  • Love
Reactions: rSl

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,583
Booth of my pandoras have awful crackles tho....
The approach is still great, despite that.
I wasnt thinking you implied anything.
Merely wanted to note: Its all a matter of usecase. And if it is the case that you dont want to use the wheel at all, we can simply do not use it right now. Which sounds not that bad, the wheel is an extra, not something we are burden to use if we dont want.
Booth other approaches however are harder to turn off.
 

netcat

Very Active Member
Joined
May 3, 2016
Messages
307
Location
city of thieves
Crackles on audio pots is almost always is due to dust ingress.
Changing the volume in most applications crackles by me. Soundcloud, spotify, etc. I use debian & pulseaudio. Bitwig which talks to alsa directly does not. What's my point? Happy Friday.
 
  • Like
Reactions: rSl

hns

Well-Known Member
Joined
Dec 4, 2011
Messages
564
Location
Oberhaching
It's an encoder wheel, I suspect the power consumption would be considerable less than polling an ADC on an interval as the wheel itself would trigger the change event. Also I wasn't implying that an Encoder wheel should have been the solution. During the original forum discussions, I was pushing something similar to the Pandora audio system honestly, it's simplistic and the audio quality was great on the Pandora.
Well every choice has its drawbacks.
Encoder wheel usually has small steps (sending impulses to wake up the processor to be counted up or down). It reports changes. Therefore there is no well defined "off" position which it can be turned to even when the system is powered off. And off-the-shelf rotary thumbwheel encoders usually do not have many impulses per revolution. So getting fine-grained control is not easy.
Potentiometer + ADC has very fine steps (limited by scratching of the potentiometer and ADC resolution and system noise). It reports an absolute level. But it can not detect changes.
When the Pyra was designed the absolute on/off position and fine tuning capability was the main requirement. Hence encoders were ruled out.
An ideal solution would maybe to have been a separate low-power microcontroller (PIC?) with built-in ADC which just monitors the potentiometer and reports both, changes (interrupts) and absolute position. I.e. the daemon discussed here would be part of the hardware. This is something for a future Pyra design. Still someone has to develop the optimal algorithm and it needs a procedure to flash that into the microcontroller before or during production.
 

MrConfusion

Very Active Member
Joined
Apr 11, 2013
Messages
331
Well every choice has its drawbacks.
...
An ideal solution would maybe to have been a separate low-power microcontroller (PIC?) with built-in ADC which just monitors the potentiometer and reports both, changes (interrupts) and absolute position. I.e. the daemon discussed here would be part of the hardware. This is something for a future Pyra design. Still someone has to develop the optimal algorithm and it needs a procedure to flash that into the microcontroller before or during production.
Yes... that solution would rock. Did I understand wrong that it was actually done with some funny looking (i.e. not a wheel) potentiometers and a couple of Atmel controllers in the Pandora? And we never had any problems with the nubs with the Pandora, the firmware for which was perfect from the get-go :oops:. Obviously doing that again on the Pyra would have made sense ;) ?

( As you said there, every choice has its drawbacks. Reading this it sounds like elw3 is progressing nicely in producing a solution that is updateable, configurable, modifyable and truly transparent. Personally I like what I see happening here. In an optimal world the SoC would have something for handling this without using up main CPU core cycles, but since that's not the case, this all sounds like a good compromise to me. Of course, if a microcontroller could be flashed by the CPU I would change my mind again :cool:. )
 

aTc

Very Active Member
Joined
Apr 25, 2009
Messages
220
I think the problem is probably in the iio driver for the palmas (or possibly the chip itself), even polling a value a few thousand times/second should hardly tax the cpu.
choosing another sensor chip to read a value from with iio (like the accelerometer) takes far less cpu.
 

levi

Still fresh, damnit!
Joined
Oct 6, 2008
Messages
14,132
Location
Somewhere off the coast of the EU
An ideal solution would maybe to have been a separate low-power microcontroller (PIC?) with built-in ADC which just monitors the potentiometer and reports both, changes (interrupts) and absolute position. I.e. the daemon discussed here would be part of the hardware. This is something for a future Pyra design. Still someone has to develop the optimal algorithm and it needs a procedure to flash that into the microcontroller before or during production.
I wonder if that could be run on the thumb-based ARM-R4 chips on the OMAP5's die.
 
  • Like
Reactions: rSl

elw3

ƐʍlƎ
Joined
Aug 10, 2010
Messages
1,583
Aaaaand another update, the last one for now. I am out of this discussion.

This brings two new arguments:
Offset - Adjust where the wheel starts, this defaults to 19 so that 10 is read as 1% instead 0%. Effectively this option also allows to reverse the wheel if you let it start at -2041. That feels surprisingly good, maybe it was meant to be used like that all along?
Command - You can now switch the command called for changing the volume to whatever you like. A simple "amixer set Master %i", and it sets the alsa volume instead pulse. Or how about binding a led to the wheel? No problem, simply set "echo %i >/sys/class/leds/logo:red:top/brightness" and the top led glows according to your _volume_.

Further "Timeout 15" is now the default and volume changes have been added to trigger going back to fast polling.

This upload also contains the little tool "currentcompare" which is handy to find out how much power different tasks take.
It simply reads /sys/class/power_supply/bq27421-0/current_now a few times and averages it.
Next you can repeat that with eg a different screen brightness and it directly spits out how much more power was used. Absolute and in %.
 

Attachments

  • vol.tar.gz
    8.2 KB · Views: 8
Last edited:

Confuzzled

Very Active Member
Joined
Oct 1, 2018
Messages
118
Thank-you very much for your efforts and contribution, elw3. I very much appreciate both.

I think the discussion shows why so many devices have buttons to control volume (up and down), rather than a wheel. It strikes me that having a combined rotary encoder/potentiometer might be a thing. Only read the pot when the rotary encoder signals movement (although whether the sensitivity of the rotary encoder would be sufficient, I don't know). It would be interesting to see how this sort of thing is done in other devices. It may be they are just dead simple and put the pot into the analogue sound output, so zero is the highest resistance (and therefore lowest volume), and the lowest resisence gives the highest volume. No ADC or cpu processing required. My other thought was mount the pot on a microswitch which is triggered when you press on the pot wheel to move it, and use that swtich to trigger ADC reads and cpu processing. I like the idea of using the ARM-R4 chips on the OMAP5's die. No idea if it is practical, though.
 
Top