snd_hdspe(4): Add sysctls to select analog signal levels.

[dev_submerge.ch]

Summary

RME HDSPE AIO sound cards support different sensitivity levels at the
analog input, and different gain levels for the analog line and phones
outputs. Expose these settings as sysctl tunables.

Test Plan

The following tests on hardware should be performed if possible:

• Phones output volume changes according to sysctl setting (caution, still extremely loud).
• Create loop to feedback the line output to line input, recording the sound played.
• Iterate through input signal levels and observe volume changes in recorded audio.
• Iterate through output signal levels and observe volume changes in recorded audio.

[dev_submerge.ch]

@br: This is the equivalent of D47330 for HDSPe AIO, as promised. Could you test it on real hardware (see test plan)? Please check that the default levels are safe, they should always be the most quiet.

There were some differences about the register used, and the RME terminology for the phones output levels is different from HDSP 9632. Watch out for copy'n'paste errors.

[dev_submerge.ch]

Fixed a typo in the man page.

[br]

Great work, thanks!

I managed to switch phone level to +4dBU and then to HighGain, but could not switch back to -10dBV which was default

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dbU
dev.hdspe.0.phones_level: -10dBV -> +4dBu

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=HighGain
dev.hdspe.0.phones_level: +4dBu -> HighGain

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dBU
dev.hdspe.0.phones_level: HighGain -> +4dBu

Fail:
0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=-10dBV
dev.hdspe.0.phones_level: +4dBu -> +4dBu

(Note that default setting (-10dBV) is loudest, then +4dbU is lower, and HighGain is lowest volume)

[dev_submerge.ch]

In D47412#1081377, @br wrote:

Great work, thanks!

I managed to switch phone level to +4dBU and then to HighGain, but could not switch back to -10dBV which was default

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dbU
dev.hdspe.0.phones_level: -10dBV -> +4dBu

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=HighGain
dev.hdspe.0.phones_level: +4dBu -> HighGain

0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=+4dBU
dev.hdspe.0.phones_level: HighGain -> +4dBu

Fail:
0 pie:/home/br %sudo sysctl dev.hdspe.0.phones_level=-10dBV
dev.hdspe.0.phones_level: +4dBu -> +4dBu

Thanks for the feedback, although I can't explain it from the code yet. I hope it's not the command line swallowing the "-" or something like that?

(Note that default setting (-10dBV) is loudest, then +4dbU is lower, and HighGain is lowest volume)

Interesting, should be the other way round. The linux code doesn't seem to label these explicitly, which is why I expected the 0 value to be safe (quiet) similar to HDSP 9632. Chances are the input and output levels work the same and are in wrong order too, could you check them?

[br]

On travel currently -- will look next week.

[br]

(Note that default setting (-10dBV) is loudest, then +4dbU is lower, and HighGain is lowest volume)

Interesting, should be the other way round. The linux code doesn't seem to label these explicitly, which is why I expected the 0 value to be safe (quiet) similar to HDSP 9632. Chances are the input and output levels work the same and are in wrong order too, could you check them?

I can confirm the line level output is also mixed around (currently -10dBV is loudest, +4dBu medium and HighGain is lowest volume).
I could not check inputs right now, but I'll get a microphone to test this next week!

[br]

On the "-10dbV" problem I could suggest to rename this to "minus10dbv" (and "plus4dbu as well).

[dev_submerge.ch]

Fix the signal level flags which were backwards, with the loudest setting (high
gain) resulting in a quiet signal and vice versa.

[dev_submerge.ch]

In D47412#1086254, @br wrote:

On the "-10dbV" problem I could suggest to rename this to "minus10dbv" (and "plus4dbu as well).

Now that I think of it, we also have negative integer values in sysctl. Given that, it should be acceptable to use "-10dBV". It is quite a bit more readable and closer to RME / standard signal level terminology.

Could you please try to set "-10dBV" in a su -l session, to check whether this is a sudo problem? I read through the code again and didn't find any possible cause.