Several issues related to recent Audio Levels refactorization

[jofemodo]

Describe the bug

• Due to the new ALSA mixer control name changes, "audio levels" config is broken for all users. In the current state they have to re-select the controls in webconf. We need a translation function that translates old names to new ones so current configs can be used/translated.

• Regarding Output Levels, the audible range for my V5 and my studio monitors is from 60 to 100. Going under 60 is barely audible at all. From 60 to 80 is super weak, I think it would be better a more linear scale, so the full range is better profited. As it used to be ;-)

• Output Level 1 & 2 are reversed in V5. They also appear wrongly ordered in the screen (Output Level 2 first). We should check that audio input controls are not reversed too, etc.

Setup:

• Vangelis & Oram Staging
• V5.1

Additional context
Connected to my studio monitors.

[riban-bw]

For reference:

The default configuration for oram-2409.4 is:

symbol	description
Digital_0	Output Level 1
Digital_1	Output Level 2
ADC_Left_Input	Input Mode 1
ADC_Right_Input	Input Mode 2
PGA_Gain_Left	Input Gain 1
PGA_Gain_Right	Input Gain 2

The corresponding configuration for vangelis (250105) is:

symbol	description
Digital_0_0_level	Output 1 Level
Digital_0_1_level	Output 2 Level
ADC_Left_Input_0_0_enum	Input 1 Mode
ADC_Right_Input_0_0_enum	Input 2 Mode
PGA_Gain_Left_0_0_enum	Input 1 Gain
PGA_Gain_Right_0_0_enum	Input 2 Gain

The symbol name changes reflect that these are elements of arrays (which was not accessible in old system) and that some are enumerations. The descriptions have changed to be more appropriate but this does not impact functionality.

We should consider what is the best format for the symbol naming convention, e.g. do we need "enum"? (I think it was needed to differentiate similarly named controls with different types.) We need to work within the naming conventions of ALSA which uses names + type + index (for arrays) to uniquely identify each parameter, hence why I added the name_x_y naming convention.

@jofemodo please consider whether the naming convention I chose is acceptable. If so I can add some migration transforms.

[Edit] I had a quick look at the code and it seems that the name_x_y convention is implemented for all parameters, not just array members. Should we maintain this for code simplicty and consistency or have different naming conventions for array and non array elements? The latter may be more challenging to code and build transforms...

[riban-bw]

Closer review of code... the format of the symbol name is: name_idx__channel_type where:

• name is the name of the control, returned by ALSA, with spaces replaced with underscores, so there may be more underscores in the symbol than just used for seperators.
• idx is the index of the control within an array or 0 if the control is not an array member.
• channel is the index of the control's channel, e.g. 0 for left, 1 for right for a stereo control.
• type is the control type which may be: level, enum or switch. This describes the type of control and how to interface with it.

There are controls with the same name, array index and channel but with different functions, e.g. mute and volume for an input may share all the same parameter indicies apart from control type, hence we need a symbol name that differentiates these.

I will try to reverse the idx/chan in the symbol name then check for symbol starting with the saved symbol name. This may match old symbol names where only the channel was appended.

[riban-bw]

I have pushed a fix for the first issue. I have mostly reverted the symbol name. "_x" and "_y" suffix are only added if the control is in an array or a multichannel parameter. "enum" and "switch" are only added if required to make the symbol name unique, e.g. there is also a volume/level capability.

Regarding output levels, I suspect this is because ALSA allows setting levels in several different ways:

• VOLUME_UNITS_PERCENTAGE
• VOLUME_UNITS_RAW
• VOLUME_UNITS_DB

I will look at this next.

[riban-bw]

I implemented all volume as percentage. I remember testing to find which worked best but maybe this issue suggests that there is not one option that fits all? Or maybe we need to configure the zctrl correctly.

[riban-bw]

Output 1 & 2 controls are adjusting the correct output but appear reversed in the view because of this commit. @jofemodo please review the change that broke this (and probably lots of other lists).