# HG changeset patch # User Mychaela Falconia # Date 1636569298 0 # Node ID 8ce3bd7c01647b6c780038f4f387f18a9ceedbb5 # Parent 468d43c0d8cbff24b9f92e05d8bb35680cafd374 Audio-tone-amplitudes article written diff -r 468d43c0d8cb -r 8ce3bd7c0164 Audio-tone-amplitudes --- /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.