So, what's the actual state of the software?

[comradekingu]

But in TWL6040-mode, why not have a visual slider or other means of signifying volume? To me that sounds like expected behavior.

Turn right, level goes up, turn left, level goes down. Not just aurally.

You could even learn where to control it should you not like to use the volumewheel, or find a better use for it.

And then those widget-popups for incoming call, mute, potentially changing tracks, etc.

 

[EvilDragon]

Um... you have virtual sliders... that's the normal volume control in the widget...

 

[matzesu]

Dos the Pyra Volume weel an Unlimited spinn, or is it like on Pandora were you can only spinn it in one direktion until its stucks??

I mean this: whit the slider on the Pyra Desctop, you go to "100%" and then you shut down the device, and spinn the volumeweel to the left.. ( 0% Volume)

Dos the Pyra if you put it one have 100 % or 0 % ??

So you have to resett it one time by use the software controller to get back to 0%..

 

[hns]

Dos the Pyra Volume weel an Unlimited spinn, or is it like on Pandora were you can only spinn it in one direktion until its stucks??

I mean this: whit the slider on the Pyra Desctop, you go to "100%" and then you shut down the device, and spinn the volumeweel to the left.. ( 0% Volume)

Dos the Pyra if you put it one have 100 % or 0 % ??

So you have to resett it one time by use the software controller to get back to 0%..

Mechanically it is exactly the same component. No difference in how it feels. I.e. it has a mechanical barrier at 0% and 100%. So it is a true position sensor and not a +/- dial.

I would do it that way: the mechanical wheel defines 0% .. 100%. And a GUI slider shows the same value. But it can be modified by touch screen/mouse or VOL+ and VOL- buttons. And as soon as you rotate the wheel (or reboot the device) it is reset to the wheel setting.

It could even be that it is already implemented in graphical amixer tools this way since there are Linux events for VOL+ and VOL- and absolute VOL values. So such widgets just have to decode these input events. Whereever they come from (dedicated +/- buttons or absolute controls). Sometimes (but not always) others have already solved the problems we are heavily discussing about.

Of course, we can imagine many other schemes which might turn out to be even more intuitive. With software, they can be changed and improved. All hardware schemes can not be changed.

 

[EvilDragon]

In my opinion, the ideal daemon should work like this:

* Normally, the hardware wheel is enabled and changes the software master volume.

* If the software master volume is changed, it should disable the hardware wheel.

* To reenable the hardware wheel, you need to move it to the current software setting and then it picks it up and takes over again.

* On shutdown, the daemon saves whether the hardware wheel was currently enabled and disabled and should behave accordingly on startup.

This is the best solution of both worlds.

If you never touch the software controls, the wheel works exactly the same as before.

If you touch the software controls, moving the hardware wheel won't make a sudden volume change.

 

[rygD]

I figured it would be good to have the option to set it at, say, 50%, and from then on, moving the physical control gives you between 0% and 50%.  If that can't happen I would prefer the Pandora way so that I can do it.

 

[Agricola]

 And as soon as you rotate the wheel (or reboot the device) it is reset to the wheel setting.

This doesn't sound like a very good idea, as just a little turn of the wheel by accident could reset any setting you made to the volume. Worst case would be a user with headphones who'd set it from 3% or so to 90%, just by an accidental swipe.

* To reenable the hardware wheel, you need to move it to the current software setting and then it picks it up and takes over again.

Even ED's way doesn't seem too appealing, as you'd have to turn it mindlessly quite a lot until it picks up the volume again - I imagine a first time user who has no knowledge about this and no clue to why his volume wheel doesn't work anymore.

The Pandora-mode with the wheel wired to the PWM of the DAC sounds most promising to me, except maybe for letting the user pick his way of controlling via a DIP switch for example (if that's even possible). But we've got to be honest here, even the worst way would be just a minor problem with the concept of the Pyra and there are other things with higher priority and the prototypes have to be finished first to back up every statement made here, so everything I've said could be just theoretical BS.

 

[EvilDragon]

* To reenable the hardware wheel, you need to move it to the current software setting and then it picks it up and takes over again.

Even ED's way doesn't seem too appealing, as you'd have to turn it mindlessly quite a lot until it picks up the volume again - I imagine a first time user who has no knowledge about this and no clue to why his volume wheel doesn't work anymore.

Which would still be better than a hardware wheel, as the software control WILL change the volume when you move it around a bit, whereas the hardware wheel will do nothing if someone mutes the software volume (which happened sometimes on the Pandora, I even got an RMA shipped back because someone thought the hardware wheel was broken).

So there's no difference in this case.

However, it should be possible hiding the master software control slider as default setting, so no newbie would fall for that trap.

 

[WizardStan]

I figured it would be good to have the option to set it at, say, 50%, and from then on, moving the physical control gives you between 0% and 50%.  If that can't happen I would prefer the Pandora way so that I can do it.

That's what I've been saying.  I'd miss this if the wheel directly controlled the master volume.

 

[Kev2442]

I like ED's system, but I'd like it to be only if master volume is lower than the wheel setting.

This way, if wheel is at 25% and master at 50%, you can use the wheel directly so that it starts from 25%, not 50.

Blocking only when the volume is greater than what the wheel shows means that it still has deafening prevention without hurting anyone who wants to easily turn the volume up.

Plus, as the volume would suddenly go down to be able to go up again, you might result in getting the very same volume than before because of the volume difference. So you won't annoy your neighbors much more.

 

[comradekingu]

What happens then if you set softvolume lower than wheel position?

Dropping log 25% when you just touch the wheel would scare me, a lot.

If I turn the wheel down to position 0, I want everything to be muted, always.

In my opinion, the ideal daemon should work like this:

* Normally, the hardware wheel is enabled and changes the software master volume.

* If the software master volume is changed, it should disable the hardware wheel.

* To reenable the hardware wheel, you need to move it to the current software setting and then it picks it up and takes over again.

* On shutdown, the daemon saves whether the hardware wheel was currently enabled and disabled and should behave accordingly on startup.

This is the best solution of both worlds.

If you never touch the software controls, the wheel works exactly the same as before.

If you touch the software controls, moving the hardware wheel won't make a sudden volume change.

User sets software volume to 100%, thinking this the wheel is a regular one, so that position of wheel : % of softvol  is the level.

Instead the software knows best, and gets really loud. User turns wheel to correct, but wheel doesn't work.

How about two software levels, one is volume, the other is sensitivity.

If you don't want to use the potentiometer, you leave it at 100% and just deal with the sensitivity, which effectively becomes the volume-control, working in the same way as gain would. It would adjust the increments of the volume, so you have solved this puzzle, by setting sensitivity once and then forgetting, but you need to use the wheel to do so.

Drawback, using the software volume is not possible.

Or,

A rotary encoder that has no stop and endpoint.

Drawback, you can't feel that you are at zero and 100%, which at least for me is comforting to know.

Which could be alleviated by setting a master volume max %.

If pulseaudio, I understand that each program only has access to its own program-level. Then there are no accidental 100% situations.

 

[Linux-SWAT]

The standard Pandora volume works fine, I don't understand why change something simple and working with an overcomplicated system...

 

[fusion_power]

The standard Pandora volume works fine, I don't understand why change something simple and working with an overcomplicated system...

Maybe to make it really idiot-proof or so? ^^ 

 

[WizardStan]

"Works fine" is fine, but can often be limited.  Sometimes you gotta break something in order to make it better.

I may not like the change but I recognize it is bringing features with it: the ability to have independent audio for headphones and speakers, and volume override for things like alarms, neither of which is possible if all audio goes through a single potentiometer.

Whether these added features are enough to balance out the lost features is a matter of pure debate.  Honestly, I think we will get over it eventually, we'll settle in and fix things the way we like them same as we always do, I just want to complain a little longer.

 

[Linux-SWAT]

So to turn off volume, need multiple operations...

 

[EvilDragon]

Hm? And what operation would that be?

Turn the volume down to zero, same as on the Pandora...?

 

[pmprog]

Hm? And what operation would that be?

Turn the volume down to zero, same as on the Pandora...?

Well, depending on where the wheel is and the software volume level, apparently you might have to spin it all the way to max, then back to min

 

[comradekingu]

If you have to bring the softvol level along, it makes more sense to draw the wheel down to 0 to re-align them.

Nothing should ever be higher volume than the % of the wheel position.

 

[PowerGod]

For me the volume wheel is useful without software involved... if I want to use software volume I use the pen, or hotkeys...

If it's output is controlled by software I consider the wheel a wasted space on the board...

 

[levi]

I always thought it a little inelegant that the Pandora has both a physical volume control and the mixer app with a volume slider, which as ED says has caused someone to be so confused they sent the unit back in the past.

I'm not sure of the best way to combine the two options are for the Pyra.  I tend to think scrolling the wheel to 0% should always mute the device, but that would mean the software slider would end up disabled, and I'm not sure the best way to square that circle.