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


Will the Pyra have the same user experience?

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.

Don't know where you got "0 to 100" here, the ADC is 10-bit (1024 values) and I really doubt you will be able to discern the difference at the resolution so long as the software works like it's supposed to.

The potentiometer is still used because people like controlling volume using it. The digitization path is really not relevant except that it means the volume position becomes available to the CPU and it can be overridden or modified if necessary.

An analog potentiometer is still used because it's cheaper and arguably easier to work with than one that outputs a discretized digital signal. It'd maybe make sense in a system where you don't already have spare ADCs you can use. But I think the look and feel is pretty different than the wheel in Pandora and people would probably prefer to keep that.
 
You can't have one driver control another without some userspace middleware or something like that.

How about updating (and if absolutely necessary, forking) the audio driver to include the option for this functionality directly? Seems like something that could be useful in other places.
 
Last edited by a moderator:
Even if it is just a wheel on an ADC for software controlled volume I'd still prefer that kind vs the infinite spinning tick-up/down kind.  With the analogue wheel you can spin it all the way left or all the way right and know it is mute or full, or once you've found your "perfect" volume easily make sure it's set there.
 
Even if it is just a wheel on an ADC for software controlled volume I'd still prefer that kind vs the infinite spinning tick-up/down kind.  With the analogue wheel you can spin it all the way left or all the way right and know it is mute or full, or once you've found your "perfect" volume easily make sure it's set there.

Good point.  I usually set my Pandora volume by turning it all the way right then 1.5 pushes left then use the slider on my headphones from there.
 
 
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.
 
So, I had another silly idea...  one wheel, multiple functions.

Lid open & wheel is nothing.
Pyra (super) & wheel is headphone volume.
Lid closed (super) & wheel is headphone volume.
Shift (either) & wheel is speaker volume.
Etc...

Ok, silly, but maybe a valid function theory?
 
I prefer the main action button to be X, so most of my ports are like that. Other prefer B as main, so you find port like that... This is no Nintendo, Sony, or other, where the whole GUI & so as to be validated and must follow some guidelines...

Yeah, but it kind of makes sense to be consistent across applications, though. For the end-user, that's the best.

That's why there should be some kind of guideline to avoid everyone using different standards for each application they port, at least to ensure they don't do it unintentionally.
That would be interesting to have one, but even if there was one, it would not be mandatory to comply to it to be allowed to publish an app.

My point is not to point out that the lack of guideline is good (and in fact it's not), but to point that even with guideline, it would be messy anyway.
I know what you mean, but as I mentioned the point of the guideline (as the name suggests) is not to enforce anything, but to recommend the best way to implement things on the Pyra. If there is no document at all, that's for sure that implementations will go in all directions. If there such a guideline, at least SOME people will follow it :)
 
foxblock, ptitSeb, ekianjo, PokeParadox, and Grench, you may want to read flipBX - Gaming buttons (non-)standardization on Pyra if you haven't done so yet. If you added your opinion or personal view there, that would be splendid, because now is the best time to discuss this (as opposed to /after/ the Pyra's release). I'd really like to hear more people say what they think of on the idea.

Thanks will have a look !
 
Last edited by a moderator:
So, I had another silly idea...  one wheel, multiple functions.

Lid open & wheel is nothing.
Pyra (super) & wheel is headphone volume.
Lid closed (super) & wheel is headphone volume.
Shift (either) & wheel is speaker volume.
Etc...

Ok, silly, but maybe a valid function theory?

Heh, if it was exposed as an input device that generated volume up/down keypresses you could do this in FunKeyMonkey :p .

Not really practical in any case because of volume depending on the absolute position of the wheel. Consider having headphones at 0% and speakers at 50%, with the volume wheel at 50%. Now try to set headphones to 10%. You'd need to go down from 50%, which is probably quite loud, even though you're technically moving up from 0%.
 
The hardware supports two modes (depending on which components are installed):
1.) Pandora mode - here the potentiometer is analog and attenuates the PCM DAC signals before they go to the headset or speaker amplifiers
2.) TWL6040 mode - here the potentiometer goes to one of the ADC inputs of the Palmas chip so that the gpadc iio driver presents a value between 0 and 100%. This can be repeatedly fed by a daemon into amixer
In both cases the position is remembered (mechanically) whatever happens.
Indeed 2.) is more flexible to configure what you really want to control by the volume wheel (headset, speaker, bluetooth, HDMI) - or even use it as a game input device...

Does this mean in mode 2 it would be possible to overwrite the volume wheel completely by software, so I could have an alarm clock in my crontab and don't have to worry how I set my volume wheel?

And btw, is it possible to control the volume of the internal speaker and the headphones independently? On one of my old laptops it worked this way, and it muted the internal speaker whenever a headphone was connected, but it could be overwritten, which was very nice.
 
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.
But it's a waste of time at the end, and a non-negligible risk to see bad designs stay forever.

While everyone was so patient all those years, being in a hurry and deliver a so-so software implementation is contradictory.

Also, about the sound loop, remember Murphy's law...
 
Well, the locking bit aside (which yeah, I guess isn't a massive issue), it's actually nice to be able to mute the Pandora whilst it's turned off... If the wheel is software based, will this still be possible?

Yes and that is the reason why we have the thumbwheel even in the twl6040+adc solution. It stores the position mechanically and its setting can be changed even if the Pyra is off. You do not need some + and - buttons and software to change it.

Although it is even possible to simulate that. Someone just has to write an input driver that reads the ADC values and detects if it was turned left or right and by which amount. And let the user space know this in the form of KEY_VOLUME_UP or KEY_VOLUME_DOWN events. Or even similar to a touchscreen/mouse driver and simply report ABS_VOLUME events.

The problem is that none of us has a complete enough hardware to really implement and test that. On the EVM systems there is no audio and no volume wheel. On the only prototype we have working yet, the connection to the Palmas chip is broken so that we can neither access audio (the twl6040 does not get it's power supply) nor can we read out the ADC values. This will change as soon as we get the first new CPU boards and the prototypes into the hands of the developers.

I think you should let us some time to implement all this (it is not difficult but low priority and therefore not already done) and then it is possible to demonstrate (ED will certainly make a lot of videos).
 
Last edited by a moderator:
The hardware supports two modes (depending on which components are installed):
1.) Pandora mode - here the potentiometer is analog and attenuates the PCM DAC signals before they go to the headset or speaker amplifiers
2.) TWL6040 mode - here the potentiometer goes to one of the ADC inputs of the Palmas chip so that the gpadc iio driver presents a value between 0 and 100%. This can be repeatedly fed by a daemon into amixer
In both cases the position is remembered (mechanically) whatever happens.
Indeed 2.) is more flexible to configure what you really want to control by the volume wheel (headset, speaker, bluetooth, HDMI) - or even use it as a game input device...

Does this mean in mode 2 it would be possible to overwrite the volume wheel completely by software, so I could have an alarm clock in my crontab and don't have to worry how I set my volume wheel?

And btw, is it possible to control the volume of the internal speaker and the headphones independently? On one of my old laptops it worked this way, and it muted the internal speaker whenever a headphone was connected, but it could be overwritten, which was very nice.
Yes, the twl6040 variant has more separate controls. But they can be connected by software.
 
While it is a trade off, IMO Pandora mode will draw more interest in the Pyra (e.g. because of awkward experiences with loud audio) than the boring standard mode. And I don't think either mode will actually turn (a significant number of) people away.
 
You can't have one driver control another without some userspace middleware or something like that.

How about updating (and if absolutely necessary, forking) the audio driver to include the option for this functionality directly? Seems like something that could be useful in other places.
Thats a huge maintenance burden. We already have pandora stuck in 3.2 kernel likely forever because of such hacks.

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.
That's again just theoretical possibility. Who will actually implement all this stuff?

The real analog wheel would just work, no need for software, no possibilities of bugs, no problems for custom kernels and OSes. With the fake software wheel everyone who installs a custom distro will have non-working wheel, if anyone does an Android port, it will not work again.

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.

I think you need to make a priority list what you think you want to be working the most, as it's pretty clear there is no way we can have everything working for release.
 
The hardware supports two modes (depending on which components are installed):
1.) Pandora mode - here the potentiometer is analog and attenuates the PCM DAC signals before they go to the headset or speaker amplifiers
2.) TWL6040 mode - here the potentiometer goes to one of the ADC inputs of the Palmas chip so that the gpadc iio driver presents a value between 0 and 100%. This can be repeatedly fed by a daemon into amixer
In both cases the position is remembered (mechanically) whatever happens.
Indeed 2.) is more flexible to configure what you really want to control by the volume wheel (headset, speaker, bluetooth, HDMI) - or even use it as a game input device...

Does this mean in mode 2 it would be possible to overwrite the volume wheel completely by software, so I could have an alarm clock in my crontab and don't have to worry how I set my volume wheel?

And btw, is it possible to control the volume of the internal speaker and the headphones independently? On one of my old laptops it worked this way, and it muted the internal speaker whenever a headphone was connected, but it could be overwritten, which was very nice.
Yes, the twl6040 variant has more separate controls. But they can be connected by software.
I'm not entirely sure I like the sound of that. On the one hand, yes, the alarm overriding the volume sounds good, but at the same time it means that even if I turn my volume off I might still get audio (which is the antithesis)
 
As a programming novice I guess the most important thing is not discuss about in threads that could rival the keyboard discussions but for a relatively small group of people to lay down the basics for these systems. Some things that already popped up in these threads could/should be implemented (like the nub issue), and others could pick up some tasks (like the screen tearing). Its good to think about things but overthinking is not always favourable.

although you could say thats how the wheel was invented

overthinking.png
 
I would be quite happy already, if at preorder time the hardware components likely to be supported by upstream drivers at release time and a realistic chance of the rest to ever be supported by upstream were documented.
 
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.
That's again just theoretical possibility. Who will actually implement all this stuff
It's not important that ALL tweaks and details work from the very beginning. It's important that it's not limited by hardware (as that can't be fixed), but only missing software, as software will evolve over time, but once you bought the hardware, it's fixed.
I've seen the GP32, GP2X and Pandora. And all of those improved quite a lot overtime. All software fixes.
 

And as mentioned already:

If no one from the community will do it, then I will hire two kernel developers Nikolaus knows. He worked with them on GTA-hardware already and they can do these things.
I'm perfectly fine paying those if no one else will pick stuff up.

The real analog wheel would just work, no need for software, no possibilities of bugs, no problems for custom kernels and OSes. With the fake software wheel everyone who installs a custom distro will have non-working wheel, if anyone does an Android port, it will not work again.
Well, yes and no.

Every distribution and Linux supports software volume control. So without that daemon, it would work the same as on every other modern device these days.
And if the daemon hooks into ALSA / PulseAudio, it shouldn't be hard to compile it for different Linux distros.

Yes, an analog wheel would be great, but as Nikolaus already mentioned, it's not really possible in a proper way with the TWL.
Sadly, it's normal these days that analog volume wheels vanish from modern technologies. That's why we're trying to recreate it as good as possible, and not just let people use buttons and GUIs to change the audio volume, something most other devices out there do.

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.

I think you need to make a priority list what you think you want to be working the most, as it's pretty clear there is no way we can have everything working for release.
Yes, I was planning to do that with the prototypes delivered, so that we have multiple devs who can work on the hardware.
I first need to make a list what's all missing first, and I'm already making notes with what I get from you, Nikolaus and Tomi.
 

I'm also planning to have a proper setup with fixed maintainers and an open mailing list, where everyone can send patches, comment, and the maintainers take care of the implementation.
 
Last edited by a moderator:
Seems to me you're both right wrt. whether stuff needs to be done before mainstream release, or can be drip-fed in afterwards.  Some things are best to be there from the beginning, but hopefully most things can be added piece-meal in later.  I tend to agree with ED more on the issue of the volume wheel - we need something that can set the master level according to the volume wheel in time for release, but all the stuff about setting min and max levels, and adjusting the different sliders according to the keys held down could all be added on later.  The sliders are still there and can be controlled by mouse/nubs until then (and min/max could be added in a later changeset)
 
Back
Top