--- a/FC-handset-spec	Sat Jun 12 23:20:47 2021 +0000
+++ b/FC-handset-spec	Sun Jun 13 01:51:24 2021 +0000
@@ -1131,3 +1131,92 @@
 a matter of project scope, we are NOT supporting backward compatibility with
 18-button keypads, given that the lowest-end Mot C1xx family already has
 21-button keypads.
+
+2.3. Audio routing
+
+TI's demo/prototype/PoC UI code from TCS211 does not use the audio mode facility
+of the RiViera Audio Service: ABB configuration remains the default set in L1
+initialization, volume control is done by calling audio_SetAmplf() in the Condat
+abstraction layer, which in turn calls ABB_DlVolume().  This design will need to
+change in FreeCalypso: we will start using the RiViera Audio Service audio mode
+facility, and the use of this facility (including correct audio mode
+configuration files under /aud in FFS) will become mandatory on all targets.
+
+The following 3 audio modes are defined for call audio routing and idle
+operation (keyclicks etc), as opposed to Melody E1 ringing covered in section
+2.4.2:
+
+Mode name	Used for
+------------------------
+handheld	Default handheld operation and idle state
+handfree	Calls in hands-free loudspeaker mode
+headset		When a wired analog headset is plugged in
+
+At the minimum, valid /aud/handheld.{cfg,vol} files will need to be created in
+FFS on every supported target; other modes can be omitted if they can't be
+entered.  /aud/*.vol files maintained by RiViera Audio Service will serve as the
+non-volatile volume setting store for each mode.
+
+2.3.1. Loudspeaker inclusion or omission
+
+The Mother's plan is to use a long press of the right side button as the command
+for entering or exiting hands-free loudspeaker mode; by this design, if this
+right side button does not exist on a given target, then loudspeaker mode cannot
+be entered.  Furthermore, our code supporting hands-free loudspeaker mode can be
+limited to just bigcolor configuration (conditionalize on LSCREEN preprocessor
+symbol), further excluding this mode from ports to alien targets like Mot C1xx
+and Pirelli DP-L10.
+
+2.3.2. Headset inclusion or omission
+
+The code supporting wired headset mode will always be included in the firmware,
+however, there will be a hardware driver function call to inquire if a headset
+is inserted or not.  If the wired headset jack does not exist on a given target,
+or more practically if it exists but we don't support it, this headset status
+function will always return "no headset" indication, and the headset mode will
+never be entered.
+
+2.4. Ringtone generation
+
+See section 1.8 for an overview of possible ways in which ringtone generation
+may be accomplished.  The only ring sound generation method supported by TI's
+TCS211 version of their demo/prototype/PoC phone UI (the version for Calypso,
+as opposed to other chipsets) is the original Calypso buzzer, i.e., Calypso
+digital waveform output intended for switching a magnetic buzzer.  The code that
+rings this buzzer will execute successfully on every Calypso target, regardless
+of whether it actually has a magnetic buzzer or not: if there is no buzzer and
+Calypso BU/PWT output is left unconnected, like it is on our Luna platform, the
+code will still run and emit the intended tone waveform on BU, but this output
+will go nowhere and no audible sound will be made.
+
+As a matter of project scope, in our FreeCalypso handset firmware we shall
+support two configurations with regard to ringing:
+
+1) TI's original buzzer configuration will be retained for lorekeeping and to
+   keep the door open for the possibility of a minimally usable FreeCalypso Lite
+   aftermarket firmware for Motorola C139.
+
+2) For our own FC Libre Dumbphone handset, we will need to implement ringing by
+   way of the same loudspeaker that will be used for hands-free calls, using the
+   Melody E1 feature of Calypso DSP for ringtone melody generation.
+
+2.4.1. Scope limitation on buzzer melodies
+
+Because the option of ringing via Calypso buzzer output is retained only for
+lorekeeping and for minimal-support alien targets, no effort will be expended
+toward playing more musical melodies via the buzzer.  Our current code (bugfixed
+from TI's original) implements just one buzzer ringing sound, consisting of
+alternating 800 Hz and 900 Hz tones, using BU mode rather than PWT, and the
+Mother currently has no plans to implement anything more for the buzzer
+configuration.
+
+2.4.2. Melody E1 ringer
+
+Our Melody E1 ringer implementation will require melody files in FFS, and we
+will also have a separate audio mode (in the RiViera Audio Service sense) that
+will be loaded during ringing.  Even though the same physical loudspeaker will
+be used for both hands-free calls and ringing, logically the two are separate
+modes, and they will be treated as separate for the Audio Service.  Separate
+logical modes will provide separate volume files, which is the correct approach:
+loudspeaker volume and ringing volume should be separate, just like how ringing
+volume is entirely separate when a buzzer is used.