[Contribution Request] Various enhancements for logarithmic volume scale settings

[Dwscdv3]

Hi EarTrumpet team,

I have experimented with the logarithmic volume scale (#228) under community settings and found several issues. I'm interested to work on these:

• Currently the logarithmic scale is not applied to volume meters, only sliders. This creates inconsistency on the UI and making the meters and sliders not visually comparable.
• Currently the dynamic range is fixed to 50 dB, it may be better make it adjustable to adapt for different scenarios.
• Show the actual dBFS value on the label instead of percentage, just like DAWs and other professional softwares (e.g. OBS Studio) do. (I'm not sure about this, open for discussion.)

By the way, I have seen several issues reporting EarTrumpet's sliders mismatch with Windows sliders while the actual reason is they forgot the logarithmic scale setting is enabled, or they just enabled without knowing what exactly this setting do. Do we need to inform the user beside the switch that mismatch is by design, not a bug?

Looking forward to your feedback or thoughts.

[riverar]

Sounds great to me. Let me know if you need any help. Regarding dBFS value: Makes sense and could even help alleviate user confusion.

[Dwscdv3]

Just noticed Windows CoreAudio API has a built-in way to set and retrieve dBFS-based volume, so things could be super easy and the manual conversion done previously by another contributor may be unnecessary.

See https://learn.microsoft.com/en-us/windows/win32/coreaudio/audio-tapered-volume-controls
The methods without -Scalar suffix are logarithmic one, they accept a dBFS value ranging from -∞ to 0.

By the way I have tested out that 1% of -Scalar API (the Windows native slider uses) corresponds to -67.5 dB, while a linear case should be -40 dB, so even the -Scalar APIs are not completely linearly.

[Dwscdv3]

Would be glad if you can provide some general information about where the settings and sliders UI codes are located, and are there other logic codes should be changed beyond AudioDevice and mock AudioDevice? That would save me a lot of time exploring in the codebase.

[riverar]

I think we already tried those APIs before the initial implementation (#228) and the curve was not ideal, settling instead on manual calculations along the 50dB curve documented here https://www.dr-lex.be/info-stuff/volumecontrols.html#ideal2:~:text=1e%2D3-,6.908,-x4 but I'm open to making it configurable / experimenting.

• Compilation requirements: https://github.com/File-New-Project/EarTrumpet/blob/dev/COMPILING.md
• Dev docs: https://github.com/File-New-Project/EarTrumpet/blob/master/EarTrumpet/README.md
• Initial implementation: https://github.com/File-New-Project/EarTrumpet/pull/228/files
• Settings: https://github.com/File-New-Project/EarTrumpet/blob/dev/EarTrumpet/AppSettings.cs
• Settings UI: https://github.com/File-New-Project/EarTrumpet/blob/dev/EarTrumpet/UI/Views/SettingsWindow.xaml
• Volume slider control (incl. peak meters): https://github.com/File-New-Project/EarTrumpet/blob/dev/EarTrumpet/UI/Controls/VolumeSlider.cs
• Audio Device: https://github.com/File-New-Project/EarTrumpet/blob/dev/EarTrumpet/DataModel/WindowsAudio/Internal/AudioDevice.cs
• Audio Device (per-channel levels): https://github.com/File-New-Project/EarTrumpet/blob/dev/EarTrumpet/DataModel/WindowsAudio/Internal/AudioDeviceChannel.cs?plain=1

Probably isn't much else you need to change? I can handle localization / translations.

Tips:

• Target dev branch; it's newer tech, runs on all targets natively, and currently targets .NET 8
• Use the VsDebug configuration in Visual Studio to test/run EarTrumpet unpackaged. This will also activate some debug facilities (e.g., the mock devices).
• Claude / GPT4-x models handle our project well so feel free to give it a shot for basic Q&A.

[Dwscdv3]

Thanks for the tour! That would be very helpful. 🥰

I didn't see any talk or code about SetChannelVolumeLevel in that PR. The implementation is seemed manually calculated from log to linear then use SetChannelVolumeLevelScalar from the very beginning. Actually SetChannelVolumeLevel saves us from the hassle of dealing with log curves, so we can just directly map the entire slider to [min dB, 0] range.

Problems mentioned in that PR such as

slider make a huge loudness change in 80%-100% range and almost no loudness change in 0%-80% range

are actually because the min dB in the first draft is set too low and the device/environment doesn't have enough dynamic range to support it, so the loudness is already below the hearing threshold at 80%. This is what I'm adding for: the second point, adjustable min dB. (CURVE_FACTOR in that PR is just another form of min dB.)

[Dwscdv3]

I need to one-way bind VolumeSlider.Maximum and VolumeSlider.Minimum according to App.Settings.UseLogarithmicVolume and App.Settings.LogarithmicVolumeMindB, so that change these settings don't require a restart. What should I do?

Edit: I figured out myself.

[BuongiornoTexas]

It may just be me, but this seems to have completely broken my set device volume action.

Given the changes, I would expect the set device volume action to allow me to specify a dB value, but I'm locked to percentage values (which seem to run from -192% to 707%, which doesn't seem right and which Windows seems to ignore - volumes always set to or close to 0dB, when I need to set around - 24.4dB.

[riverar]

Uh oh, @Dwscdv3 we forgot to test Actions support. Will do so ASAP @BuongiornoTexas.

[BuongiornoTexas]

Thanks (I just had a surprise light deafening, and spent 20 minutes chasing EqualiserAPO, which is the usual culprit, before tracking this down).

As ever great software, and I'll revert to non-log until this is sorted.