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.