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

[Grench]

I have to check, but I know I found it somewhere hidden away...

Well regardless, the point is that it's a feature to be able to set two volumes, a software for the maximum and the hardware for full spectrum, and reducing it to just software volume subtracts this feature, a feature which I rely on.

Would't the software option be better for that though as each output becomes discrete?  I e independent software volume (attenuation) for each output?  With the presence check on headphone connection, it could auto switch to the headphone dynamic range, which could then be user definable.

It's still a more complex scenario and control application dependent vs a dumb dial.

 

[EvilDragon]

You can also easily change the software volume of the main output roughly and then use the slider for the output stream to fine tune it.

That works perfectly (at least on Windows 7 and with Pulseaudio).

It's similar to normal audio mixing, where you have gain for the coarse setting and the fader for the fine setting.

In this case, master volume is the coarse setting and the stream the fine setting.

That should work A LOT more accurate and finer than an analog audio wheel.

 

[WizardStan]

I'm not saying there aren't solutions, I'm just saying that this is my use case, a thing which works perfectly out of the box.  Turning the hardware wheel into a software control *will* require some kind of adaptation.  If I have to then I have to, and if it brings additional features then all the better, but I'm not going to pretend that it isn't a bother.

 

[comradekingu]

I tried, but alsa documentation wasnt what my head wanted for me right now.

Setting gain by softvol isn't ideal though. With a wheel you don't really know where you are, sliders were out of the question.

The only discernible difference should be seeing a slider onscreen.

Maybe it can take control of a row of leds for while you are sliding around to signify volume?

That means you can see where you are at, without having audio playing, when you are fullscreen something other than the desktop. Then again it could be that these widget type things have gotten smarter.

 

[EvilDragon]

You also don't see where you are with a hardware wheel, and it will work the same here.

 

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