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

[Exophase]

I also like the idea of configurable default buttons.

But it needs to be done in a way that even not very experienced porters (like myself) can implement that in their ports.

I know how to change SDL button configs when porting a game... would that "Action"-Button have it's own SDL keycode, or how would that work?

The proposal is to implement it through environment variables, so the code would look something like this (in C):

const char *confirm_key_str = getenv("PYRA_ACTION_CONFIRM");
int confirm_key = PYRA_ACTION_CONFIRM_DEFAULT;
 
if(confirm_key_str)
  confirm_key = strtol(confirm_key_str, NULL, 10);
 
// ... code here, get key code
 
if(SDL_key_code == confirm_key_str)
  // Do confirm stuff

 

[Exophase]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

I don't know why people are so worried about this. If the device hard freezes you'll want to reboot it anyway.

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. Functions like this and some other things might actually fit well on one of the Cortex-M4s, but I don't think people will be very happy about the OS reserving one for internal use even if they'll probably never actually use them (let alone both)

This design has some decent advantages. Principally, being able to display the wheel's level on the screen. But it also means you could hypothetically change the volume curve (eg raising or lowering the logarithmic coefficients), rebalance left/right error, or ignore it entirely if it breaks instead of risking it ending up always open and therefore killing audio.

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.

 

[Christoph.Krn]

The proposal is to implement it through environment variables, so the code would look something like this (in C):

const char *confirm_key_str = getenv("PYRA_ACTION_CONFIRM");
int confirm_key = PYRA_ACTION_CONFIRM_DEFAULT;
 
if(confirm_key_str)
  confirm_key = strtol(confirm_key_str, NULL, 10);
 
// ... code here, get key code
 
if(SDL_key_code == confirm_key_str)
  // Do confirm stuff

Where was this proposed? IRC?

So if you have one application that by default assumes PYRA_ACTION_CONFIRM on (B) and, say, PYRA_ACTION_BACK on (A), but the user has PYRA_ACTION_CONFIRM set to (B), and PYRA_ACTION_BACK to (X), then what is the software to do if (X) was supposed to be some other function? What if the user has set even more variables, and there's even more conflicts? What's the proposed solution to this? Is there something I'm not seeing here?

 

[TrashyMG]

What I'm worried about with option 2 is lack of control when the CPU is bogged down or perhaps if it's in a state where the software isn't in control of the hardware, such as low-level use, using an alternant OS and etc. 

I don't know why people are so worried about this. If the device hard freezes you'll want to reboot it anyway.

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. Functions like this and some other things might actually fit well on one of the Cortex-M4s, but I don't think people will be very happy about the OS reserving one for internal use even if they'll probably never actually use them (let alone both)

This design has some decent advantages. Principally, being able to display the wheel's level on the screen. But it also means you could hypothetically change the volume curve (eg raising or lowering the logarithmic coefficients), rebalance left/right error, or ignore it entirely if it breaks instead of risking it ending up always open and therefore killing audio.

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.

I'm not talking about freezing, I'm talking about delayed response time by just general CPU usage... or lack of control of sound when in odd software states. It's a usability annoyance to depend on software that could fail to turn down the volume when in a crowded room and such. I also like to know 100% of the time when I plug in my headset it turns off the speakers.  

Not everyone plans on using the same OS or even Kernel, to me the Pandora method is simpler and less of a usability nightmare. If this was all done with a microcontroller independent of the kernel/OS sure maybe I could see it as a good option.

 

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

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.

The #2 reason stems back to when I used to run Windows, I once started it up in the middle of a library and it played 5 seconds of startup noise really loudly and I couldn't mute it because the software for controlling that hadn't started yet.  A flick of the wheel would have solved it.  But this can be solved in other ways, like making sure the volume daemon is started before it's allowed to play any audio at all.

 

[hns]

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.

 

[levi]

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.

 

[Grench]

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.

 

[pmprog]

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?

 

[Eight Bit]

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?

 

[FelixNemis]

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.

 

[thatgui]

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

 

[notaz]

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

 

[Grench]

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.

 

[notaz]

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

 

[TrashyMG]

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. 

 

[Haraldur]

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.

 

[Linux-SWAT]

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.

 

[Exophase]

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?

 

[notaz]

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?

You can't have one driver control another without some userspace middleware or something like that.