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

[Grench]

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?

 

[ekianjo]

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

 

[ekianjo]

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 !

 

[bzar]

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 .

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

 

[ashcloud]

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.

 

[Linux-SWAT]

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

 

[hns]

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

 

[hns]

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.

 

[_jr_]

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.

 

[notaz]

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.

 

[pmprog]

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)

 

[Bosbeetle]

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

 

[_jr_]

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.

 

[EvilDragon]

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.

 

[levi]

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)

 

[comradekingu]

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.

Considering the sensitivity of headphones vary, if it is done in TWL6040 mode, a soft limit (max level) can be set so that the loudness never exceeds damaging levels by the user.

Going the route of resampling the level down to attenuate the signal would make it very nice to have 24bit depth to work with on the DAC.

Also I think it would be less prone to scratchy potentiometer troubles, not being directly in the audio-path, which from a returns point of view could save a lot of trouble and cost.

Question, will the potentiometer, or tacho, spin all the way round? Im thinking if you set the level in software you would end up at the wrong place vis-a-vis the hardware, so that if you try to bottom it out on the wheel, it could still be playing audio.

 

[rSl]

good to hear that the twl vs. pandora audio circuit
shootout is still planned.

when i did some research on the audioquest dragonfly dac
(which i bought some time ago and sounds really awesome
to me with the beyerdynamic dt990 pro headphones) i read
that lowering volume in the digital domain reduces the
bitdepth somehow, so it would degrade audio quality.

(maybe a myth, i allready got healed from
the hires-audio crazyness by binky telling me the
shannon-nyquist theorem. thanks again binky!)


the developer of that dac was proud of the
solution to have an analog volume control that one can
change digitally via the os's volume slider,
which makes sense to me for a desktop computer, so you
don't have to reach to the dac each time you want to
change volume.
for a handheld i would prefer a thumbwheel to control
the volume, it's allready 'on hand' and one can reach
it easily.

also i plan to use pure alsa and no pulseaudio on my
future pyra, so please keep it k.i.s.s. and alsa-only
friendly.

so i think i'm still for the pandora circuit with the simple
analog volume wheel being truely analog.

 

[TrashyMG]

It will have pulseaudio, feel free to uninstall it.

 

[Grench]

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 .

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

I already thought of that.  In the 'digital wheel' model using the TWL6040 audio, the change from one 'level' to another should create a signal.  In the above model having no button pressed and the lid open does nothing.  This allows the user to pre-position the wheel to approximately where they want it, then press the shift/Fn/Alt/Ctrl or combination of those and turn the wheel 1 unit in any direction to have that particular audio output or system input or other jump to that level.  So, you could pre-position it to approximately 50%, hold Super/Pyra and then turn the wheel slightly to have the headphones jump to that level and be 'run' up/down from there.

So - it would be possible and semi-practical, but still completely silly and irrelevant for the current stage of development.

The important part is to understand that the wheel can be interpreted digitally by the TWL6040 OR analog by the Pandora-type on it's pre-amplifier side, but not both.  There are technical whiz bang features that could theoretically be implemented in the far future by having it digital on the TWL6040.  There is an audiophile draw to having a true analog wheel on the pre-amplifier circuit on a setup with big dedicated capacitors on it's own special amplifier.  Understanding the trade offs.  

The bigger unanswerable question right now, though, is, under each option, "How does it sound?"

 

[WizardStan]

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 think you are misunderstanding.  My headphones, on my desktop without hardware volume, have a software volume range of 0 to 3%.  If I set it to 4% that's too loud for me, and 5% will kill me.  I can crank it to 100% and you can hear them from the other side of the office.  I have never seen a volume slider let you choose decimal volumes, so I'm not entirely certain how you expect such a thing to work.  If I set the minimum volume at 0 and the max at 5 it's still going to be discrete steps from 5 to 4 to 3.

This is why I like hardware volume.  On my Pandora using the same headphones I have the software volume set to 5% and then I just adjust the hardware volume wheel depending on the situation, and it's a smooth transition from loud to quiet.