Linearize rm-750 audio driver volume control

[mha1]

Please set volume control to Special Function Volume, Source Pot S1 or S2 and observe volume for different Pot positions. Compared to the TX16s the TX15 volume control is very non linear compared to the TX16s. The TX16s has a nice linear volume output from Min (Off), Center (half volume), Max (max Volume). The TX15 has nearly no volume increase going from Min to Center with Center having just a little volume far from half volume. Nearly all the volume range takes place from center to Max.

Summary of changes:

• introduced a linearization curve
• integrated zero volume value in curve
• integrated 90% volume limit in curve

[3djc]

Actually I much prefer it the way it currently is, where you have fine control when at home/night, and when in open air, you just crack it up. The current scale is actually linear in dB

[raphaelcoeffic]

Since this change is highly related to a particular board using this driver, I would expect the lookup table to be located in the TX15 specific code and not in the generic TAS2505 driver, which might be used later by others as well.

[pfeerick]

The TX16s has a nice linear volume

Don't you mean logarithmic? As volume is almost universally adjusted in a logarithmic manner.

The current scale is actually linear in dB

Which is exactly the reason it would be wrong... do you know of any mainstream appliances where the volume is altered in a linear rather than logarithmic fashion? I think not... they are specifically implemented so that the perceived change in audio (not dB) matches the movement of the knob / makes it, so the full range of the knob is useful.

[mha1]

Don't you mean logarithmic? As volume is almost universally adjusted in a logarithmic manner.

Yes, it's more like trying to achieve a db(a) characteristic that fits the human ear's perception of volume.

Have you tried a before/after with the TX15?

[3djc]

Previous radio (but X12S and possibly some Flysky, I do not know) use a audio routine that dates AVR time, where doing logarithm calculations was just a dream if you wanted to maintain performance, so volume is linear on those (

edgetx/radio/src/audio.cpp

Line 658 in 6c1af5a

buffer->data[i] = (int16_t)(((tmpSample * currentSpeakerVolume) /

)

TX15 does add a dedicated audio amplifier with volume control, which logically applies a dB scale for volume control.

So are they different ? Yes
Was TX16S ideal ? Nop a simple basic linear volume

If anything, since we can do more calculation on F4 processors than AVR times, it is those older radio we should modify to have logarithmic volume control, not disable it on more performing radio

[mha1]

@pfeerick Tested headphones and speaker ok after rebase to current master. Can you please decide if you want to merge or scrap this?

[J-Sorenson]

Is there a way to get a community vote on this? I prefer the current logarithmic audio scale on the new TX15 compared to my old Zorro. I don't want to add yet another feature by suggesting we make the scale selectable (the GUI is cluttered enough). I figure those that want to assign volume to a slider and make it "just right" can use a curve. Granted, we don't have global curves, so it would have to be copied to each model or made into a Lua script.

The problem is that if this were to get merged, would I lose the resolution of setting the lower volume? I can't fix that with a Lua script.

[mha1]

The problem is that if this were to get merged, would I lose the resolution of setting the lower volume? I can't fix that with a Lua script.

No you wouldn't. Look at both tables (old vs new) and/or the graph. Both use the same range bit with different distribution.

[mha1]

@pfeerick Please give it the boot if you don't like it but please make up your mind.

[J-Sorenson]

The problem is that if this were to get merged, would I lose the resolution of setting the lower volume? I can't fix that with a Lua script.

No you wouldn't. Look at both tables (old vs new) and/or the graph. Both use the same range bit with different distribution.

I said resolution (step size), not limits. Perhaps this issue could hang for a while until more new owners chime in.

[mha1]

The problem is that if this were to get merged, would I lose the resolution of setting the lower volume? I can't fix that with a Lua script.

No you wouldn't. Look at both tables (old vs new) and/or the graph. Both use the same range bit with different distribution.

I said resolution (step size), not limits. Perhaps this issue could hang for a while until more new owners chime in.

Exactly the same resolution. 24 volume steps (including zero volume)

[J-Sorenson]

Exactly the same resolution. 24 volume steps (including zero volume)

Of course it's always 24 "steps". The point of this issue is what decibels each step should be at the upper vs lower end. Look, your concern is that something changed from what you are familiar with. My point is that the new divisions are better. We don't have a clear consensus on what the final curve should be unless we can get more feedback. It won't be decided between us two.

[mha1]

Exactly the same resolution. 24 volume steps (including zero volume)

Of course it's always 24 "steps". The point of this issue is what decibels each step should be at the upper vs lower end. Look, your concern is that something changed from what you are familiar with. My point is that the new divisions are better. We don't have a clear consensus on what the final curve should be unless we can get more feedback. It won't be decided between us two.

I'm not arguing with you, just answering your questions.

[mha1]

Btw, upper and lower level are the same too. Max volume is the same max volume as the current implementation, off is off in both too.

Lookup table has been moved as requested.

[deadbytefpv]

I'd like for this to be considered.

I don't mind too if it's through a build flag.

[Pencilvestr]

I'd also like for this to be the normal.

[Pencilvestr]

I saw this got pushed. Will this also apply to the tx16 mk3?
I used a build mha1 made for me and it was working perfectly.

[mha1]

Will this also apply to the tx16 mk3?

Yes, the TX16sMK3 uses the same audio driver

[OzDruiD]

Pretty impressed with this - top and bottom may technically be the same. but 'feels' better\more consistent.
Volume at mid-detent is amazing - and whilst sounds slighly different to Mk2 - as expected with diff electronics\speaker\radio accoustics, the implementation is FAR better than current method.

Please please normalise this into the build - or if necessary make it an audio option we can have ON \ OFF and not a rebuild flag each release. Dropped some before\after videos into EdgeTX discord as well. https://discord.com/channels/839849772864503828/839849772864503832/1498268287123984485