--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Audio-tone-amplitudes	Wed Nov 10 18:34:58 2021 +0000
@@ -0,0 +1,43 @@
+In our current Luna development setup, we use a wired headset (currently
+FC-HDS4, previously iWOW's) as our primary audio device, connected to Iota EAR
+output, and the same arrangement will be used on FC Venus, our planned successor
+to FC Luna.  The gist of the situation is that the firmware "thinks" that we are
+in the classic handheld setup, but in reality it is a headset inserted into the
+developer-operator's ear canal.
+
+The amplitudes of various audio tones emitted by the firmware through the DSP
+need to be adjusted for this in-ear headset reality, in order to provide
+reasonable ear comfort to the developer-operator and to prevent hearing damage.
+The "classic" amplitudes for fw-generated audio tones (-7 to -5 dBfs) make sense
+for a true phone handset with a 32 ohm earpiece speaker, and furthermore, these
+"classic" tone amplitudes are only appropriate when the tones are generated
+while the user holds the phone away from her ear - otherwise they are too loud.
+But in our use case where an FC-HDS4 headset stays in the developer-operator's
+ear canal for an entire work session, we need much lower tone amplitudes.
+
+Basic keybeep: the empirically found amplitude for operator comfort is -26 dBfs
+for each of the two single tones.
+
+DTMF keybeep: the empirically found amplitude for operator comfort is -29 dBfs
+for the low tone and -27 dBfs for the high tone.
+
+Approximately good amplitudes for the remaining tones:
+
+Call waiting tone: -23 dBfs
+Ringing tone: -28 dBfs
+Radio acknowledge (currently unused): -26 dBfs
+Busy/congestion/dropped: -27 dBfs
+SIT error tone: -28 dBfs
+
+All of these dBfs numbers listed above should be regarded as starting points
+for possible further tuning once we implement the necessary framework in our
+firmware for generating audio tones at configurable amplitudes - and this
+implementation most likely won't happen before FC Venus: Condat's entanglement
+between audio tones and the buzzer needs to be detangled first, and that task
+requires a platform with a working buzzer.
+
+With our present firmware, the only way to test different audio tone amplitudes
+is via AT@TONE test command, which requires 16 numeric arguments.  The high
+effort of repeatedly composing these complex AT@TONE commands for each tested
+amplitude of each tested tone creates fatigue, which then interferes with the
+original objective of psychoacoustic testing of different amplitudes.