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



Is there any reason that the pot output isn't routed to the PMIC ADC input in the Pandora-style circuit? That'd at least allow volume display.
In the twl6040 solution it is (Palmas GP-ADC). In the Pandora like solution the potentiometer is used for audio signals so that it can't be connected to any ADC.
 
FWIW, I remember often on old computers crashing the userspace such that whatever was filling the sound buffer stopped doing so, but the OS kept playing it over and over.  I've not had that happen on linux, except when I'm using the computer as a music player and let it go to sleep (usually when I'm using it as a music player outside in the summer, and the battery runs down).  When I've plugged the machine in and the system restores, mplayer gets into a right mess and won't stop squarking at you until you quit it.
 
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?

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.

That may sound  strange, but there is almost a steam-punk feel of inserting analog controls (nubs & volume control) in an otherwise digital device that adds a special something that is difficult to describe or measure.

Is it possible to build prototype boards that can do both - i.e. a set of switches to change whether or not the Pandora method is active?  For this test it would even be OK if a person would have to disassemble the Pyra's case to flip a few dip switches or pull/place a micro plug or jumpers or the like.  Is there room on the board to have those put in the pick & place?  If it's a royal pain, then it may not be worth the effort though.  However, if that's not too difficult, it may be worthwhile to get some additional opinions from the whole prototype audience.  They are all going to have different ears and different headphones of varying quality.
 
Last edited by a moderator:
  • Like
Reactions: rSl
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?
 
Though I like my Pandora's volume control because I can be sure the sound is off when the wheel is down, it has some downsides too.

First is the uneven slope between left and right, especially at low volumes the difference is audible very much. Also the wheel tends to crackle from oxidation (It think) Some back and forth turning of the wheel removes it though.

Those problems would be gone with a digital encoder wheel. Also the wheel could be configured with a min/max or fine tune setting/profile I guess, As far as the impedance goes, the output gives as much juice as it gives at the maximum right?
 
Last edited by a moderator:
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, since as soon as it's turned back on it'll read the position of the wheel, adjusting it while it's off should work the same as if it was directly connected.
 
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 ?

As for the scenario for having independent outputs: I often go to sleep having a audiobook playing through earbud(s), while I surely would miss the alarm sound to get up in the morning if it would be played through the earbuds instead of my smartphones loudspeaker
 
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.

IMO this should be implemented at the kernel level, with a timer IRQ monitoring the ADC or perhaps an ADC level change trigger if the chip supports it.

This is not allowed in mainline kernels, the drivers must stay isolated...
 
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 ?

As for the scenario for having independent outputs: I often go to sleep having a audiobook playing through earbud(s), while I surely would miss the alarm sound to get up in the morning if it would be played through the earbuds instead of my smartphones loudspeaker

So, if I understand it right, in theory, using pulse audio with the TWL6040 and the volume wheel working as an input, it should be possible to:

1.  Have an alarm sound through the Pyra's speakers.

2. Be watching a show or playing a game on the LCD and listening to it's sound track via headphones.

3.  Be watching a show on a big screen via the HDMI output and listening to it on the HDMI output in English.

4.  Be able to provide a secondary audio track to one or more connected bluetooth devices in German or other.

5.  Be able to answer the phone on yet another connected bluetooth device.

All simultaneously.  The actual function of the volume wheel could then be assigned to any one or more of the audio streams - or even screen brightness or playback speeds for that matter.

However, if we use the Pandora discrete amplifier method, the volume wheel would be truly analog and inexorably tied to the headphone and speaker audio outputs.

Did I get that right?

There are definite trade offs either way.
 
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...
 
Last edited by a moderator:
On uevm which is completely different board... Have you even decided if it it will be pandora's audio with real analog wheel or default codec with messy software wheel handling?

Oh wow, I thought the whole point of having a volume wheel was that it was a 100% hardware control - so you could mute the device even if it'd locked up.
Well, I cannot remember that the Pandora ever locked up and made some weird noise... doesn't really happen often these days (if it even does).

I've asked Nikolaus, what the final solution for that is.

But: With a modern chip, every connector has it's own volume controls. So headphone port and speakers are two different output devices and use two different volume controls.

That also means that you can have different audio coming out of the speaker than via Bluetooth, Headphones or HDMI.

It's hard to find the best solution here.
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...
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. 
 
Last edited by a moderator:
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.
 
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...
Notaz is right.

Not only we witnessed what happened in the OP project (and as not being a dev, I missed more than I think), but a few years ago, I used to work in a company who lost one year fixing stuff that were badly thought/designed, then after realized it had no other choice but to rewrite from scratch most parts of the software during one year more.
 
This is not allowed in mainline kernels, the drivers must stay isolated...

What does this mean exactly? You can't include a kernel module that attaches an IRQ?
 
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.
 
Back
Top