I have the following situation on my computer with volume only control: my volume is only at 3% with these headphones. I don't have a great deal of accuracy when I do need to adjust the volume for any reason. If my headphones had a hardware wheel on them I could crank that way down and then software adjust from 0 to 100% as needed, and that would be fine.
You can control this for the speakers, drive them in such a way that the volume is good at 100%, but you can't control headphones, different headphones will have different impedance which means different volumes at the same output level. And not just the impedance, but different headphone styles will behave differently.
Well, that wouldn't be an issue, as you could choose a maximum and minimum audio volume and the volume wheel would then let you change the volume inbetween. So you can decide the accuracy.
This is the #1 reason I want actual hardware volume control, so that I can use any headphones I can get and still get decent volume adjustment.
That doesn't have anything to do with hardware control. You can do the same (even more accurate) with software, but smartphones, MP3 players, etc. have annoying steps that make them that inaccurate.
That's also the reason I wanted to keep an analog volume wheel which is then converted to the actual volume and NOT one of these annoying digital wheels which sent out signals when you turn them around... and around... and around...
I'm not sure how the signal path was actually wired, but in the Pandora the user experience was:
I have sound through the speakers. I can control the volume from off to full volume with a hardware wheel. If I plug in headphones, the speakers are disconnected and the sound comes through the headphones - and uses the same control. There is the ability to get line level outputs through the special dongle - but that is not controlled by the volume wheel. The volume control for the speakers and headphones felt very physical - as in direct control over the output to the speakers. In application software volume control became borderline moot - could be used as a quasi-mixer to change the proportion of the sound to be from different applications.
Will the Pyra have the same user experience?
Yes, that's possible. Any volume control can be connected to the volume wheel, which means the global volume, headphones volume, speaker volume, etc.
If it's connected to global volume, it would work the same as on the Pandora.
You could even connect it to the volume of a single program (Pulseaudio supports that).
Yes, that all needs to be coded, but it is certainly possible.
I may be misinterpreting it, but it sounds like the Pyra's TWL6040 mode analog volume wheel is simply generating a signal measured digitally between 0 and 100 that is then passed to the mixer to control...? If so, then what is the point of having it on an analog wheel? This alone has me leaning towards the 'Pandora mode' option - even if the audio quality is equal.
There are mainly two advantages:
1. Digital volume wheels have no beginning and no end. They turn and turn and turn, etc. So you have no idea where the volume is when you're booting up. This is annoying. With the analog wheel, you still have a 0% and 100% for the volume.
2. Those digital volume wheels have steps. And it was impossible to find one with proper steps. I think to have the same accuracy as on the Pandora analog volume wheel, you need to turn it 8 - 10 times fully around... annoying. The analog offers a LOT more steps and therefore is more accurate.
Great, back then when I argued against having a volume wheel on the Pyra the scenario of the Pyras OS beeing unable to process the users loudness ajdustment was the reason to keep it and now thats out of the window anyway ? Why is there a volume wheel after all ?
Because I personally hate devices where you need some button combinations to change the volume while playing a game, listening to music, etc.
Also, using buttons is annoying and inaccurate, a volume wheel works WAY better:
The twl6040 isn't emitting noise by itself and it can't read eMMC or SD cards. So if you play music by aplay, this also needs the CPU to run and provide the sound data. So output will simply stop as well.
The audio on OMAPs (and many other systems) runs from a circular buffer. So if you get a sufficiently bad crash it will loop (DMA to still playing mcbsp buffer) with no possibility to stop or turn the volume down.
Okay. Has anyone here ever experienced that on the Pandora (or any other similar device)?
If that rarely happens, then I don't think it's something to worry about.
Unless it happens once or twice per week on every unit.
I think all userspace controls should be dropped and moved to the input daemon. That will make it compatible with mainline, and must be done early so nothing depends on the old stuff. So quite some work here.
Such things can be improved in the future. We also improved a lot of the Pandora over time, so the Pyra doesn't need to be perfect from the beginning.
Like others said, no they can't unless you are ok with breaking lots of software already relying on it...
Of course I would be happy to have that all finished and done when the units are ready for delivery.
But first we need to make sure all the basic hardware works.
After that, we can start to implement it properly.
The more we can finish until it's time for delivery, the better. But I know we don't have a lot of manpower, so I have to accept that this might not work out from the very beginning.
First the mandatory things, then all improvements.
I spent a bit of time thinking about option 2 on the way home as I have a long drive. In this design since it's only one volume potentiometer and one ADC input, how are you keeping separate volume settings for each audio source? How can you for example change the HDMI output volume to a set point and then change the headset audio volume to something different? I can think of some kind of channel select method where the software knows you are set on one source and it can write the set value to that specific device resource Alsa can read.. but what happens when you toggle to the next audio source in the list of audio sources/outputs, wouldn't this essentially write over the prior value with the latest ADC reading from the potentiometer? I can see the potential of accidentally setting things to values you never intended to just because you selected the source via some hotkey or accidentally highlighted it in an volume control GUI. This is of course on the assumption of how I perceive it's going to work, maybe it's a bit more elegant than I think it is.
Well, it's all software controlled.
The daemon could e.g. handle these accidental switches by only setting the volume if someone turns the wheel after the switch. It could also be coded that you need to turn it at least over the current volume setting before it reacts.
That would make things smoother and prevent sudden volume jumps.
Most users will probably use it for global volume only (like myself), so that toggling could also be disabled.
On the Pandora, there is a software volume control in addition to the volume wheel. Would it be possible to use the volume wheel as a global control, completely hardware-based, for all channels, with software (pulseaudio?) controlling volume for multiple applications and directing the audio streams to different devices? There could be a default volume for all applications, with certain applications having special values -- such as the phone-call alarm program, the general alarm program etc. getting maximum (software) volume through the speakers at all times.
If it was possible, then we could have most of the capabilities of a completely digital system but also with the ability to shut off or vary volume even if ALL the software malfunctions.
Yes, of course that's possible, as every audio system on Linux also has a global volume control.