Improve Volume Wheel Daemon (Bounty!)

[Risca]

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]

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]

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]

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.

 

[elw3]

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.

 

[levi]

Crackles on audio pots is almost always is due to dust ingress.

 

[TrashyMG]

Some well placed contact cleaner should take care of crackling.

 

[netcat]

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.

 

[hns]

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]

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 . 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 . )

 

[aTc]

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]

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.

 

[elw3]

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 %.

 

[Confuzzled]

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.

 

[netcat]

put the pot into the analogue sound output

bingo

 

[stevenc99]

I just remembered... the OMAP5432 CPU in the Pyra contains (same as with the AM335x) two fully-programmable Cortex M4 microcontrollers: https://pyra-handheld.com/boards/threads/arm-m4-usage.82072/
I wonder if they're able to handle polling of the volume wheel ADC in the background... and then accessing that stored value in userland would be super-fast (read directly out of main memory).
We even have a few people on the boards who know how to use the Cortex M4. I just don't know if the necessary kernel and toolchain support exists for Pyra yet.

 

[netcat]

you're too smart for this thread. sorry.

 

[elw3]

And where exactly is there profit in this?
It doesnt matter which chip empties your battery.

 

[Eight Bit]

And where exactly is there profit in this?
It doesnt matter which chip empties your battery.

It reliefs the main cpu?
I think it's a decent idea to run system daemons over the M4 if that's even possible

 

[pyrat]

And where exactly is there profit in this?

Hoping I'm dumb enought to speak here.
If the task is simple enough for a M4 copro to carry ...

It doesnt matter which chip empties your battery.

It matters if different chips empty the battery at different speeds. I assume an M4 core drains less battery than the main CPU core, and it would hopefully let the CPU sleep (if we ever get sleep, which is unlikely, who would guess that the Pyra, a child of @EvilDragon, would be able to sleep? It's not something she might have learnt at home, is it?).