--- a/doc/Current_Status	Sat Oct 15 04:43:35 2016 +0000
+++ b/doc/Current_Status	Sat Oct 15 05:15:23 2016 +0000
@@ -58,43 +58,21 @@
 * In the case of voice calls, the call downlink audio is routed to the phone's
   earpiece speaker and the phone's microphone serves as the source for the
   uplink audio, i.e., even though the LCD and keypad are dead with our fw, the
-  earpiece and mic continue to function as in a conventional phone.  FR and EFR
-  codecs work correctly (EFR was broken until recently), but AMR does not work
-  with this fw for some not-yet-understood reason, hence by default our fw
-  currently advertises to the GSM network that the MS only supports FR, HR and
-  EFR codecs.
+  earpiece and mic continue to function as in a conventional phone.  FR, EFR
+  and AMR codecs all work correctly (EFR and AMR were broken until recently),
+  but our default build configuration has AMR disabled (the fw advertises to
+  the GSM network that the MS only supports FR, HR and EFR codecs) to err on
+  the side of safety: we are having some reliability issues with the
+  L1_DYN_DSP_DWNLD feature (which is also disabled by default), and AMR is
+  believed to depend on one of these dynamically downloaded DSP patches.
 
   There is also a highly experimental and minimally tested alternative mode
-  of operation in which the traffic channel carrying FR codec bits (260 bits
-  every 20 ms; it is not known whether or not this feature will also work with
-  EFR) is rerouted away from the internal vocoder to the external host,
-  such that you can receive the downlink voice bits digitally instead of
-  listening to them in the earpiece speaker, and you can substitute your own
-  uplink bits instead of the microphone-fed internal vocoder output.  See the
-  TCH-special-feature write-up for more information.
-
-There are also two known bugs which manifest only intermittently, but the
-misbehaviour does occur often enough that you will likely encounter it:
-
-* Sometimes something gets messed up in the voice uplink path such that the
-  downlink audio sounds just fine in the earpiece speaker of the phone running
-  FC Citrine, but the far end of the call hears only silence.  Other times the
-  voice audio passes just fine in both directions.  It is not currently
-  understood what factors determine whether it will work or not.
-
-* Sometimes the L1A task in the firmware (see the Firmware_Architecture
-  write-up) appears to stop running; the externally visible behaviour is that
-  the debug trace output from L1 suddenly stops while the rest of the firmware
-  keeps running.  GSM firmware without working L1 is unusable, hence when the
-  fw gets into this state, the only remedy is a power cycle reboot.  It is not
-  currently understood exactly what happens and under what conditions.
-
-Going forward, the current plan is to wait until our FCDEV3B hardware gets built
-before any attempts will be made to go after the above-listed bugs.  I, the
-principal developer, am sick and tired of limping along with Compal, Pirelli
-and Openmoko hardware when we have a design for our own FreeCalypso development
-board which, when built, will be a much more convenient platform for firmware
-development.
+  of operation in which the traffic channel carrying FR or EFR codec bits
+  (260 bits every 20 ms) is rerouted away from the internal vocoder to the
+  external host, such that you can receive the downlink voice bits digitally
+  instead of listening to them in the earpiece speaker, and you can substitute
+  your own uplink bits instead of the microphone-fed internal vocoder output.
+  See the TCH-special-feature write-up for more information.
 
 Target-specific usage instructions
 ==================================