[docs] guide: document current Looking Glass features

client/DEBUGGING.md

@@ -1,32 +1,49 @@
 # Debugging the Looking Glass Client
 
-If you are asked to provide debugging information to resolve an issue please
-follow the following procedure.
+Start by running `looking-glass-client` in a terminal and retain its complete
+output from startup through the fault. It records the selected transport,
+renderer, display server, import method and audio backend.
 
-## If you're experiencing a crash:
+## Crashes
 
-Run the program under the `gdb` debugger (you may need to install gdb), for
-example:
+Run the matching binary under `gdb`:
 
-    gdb ./looking-glass-client
+```text
+gdb ./looking-glass-client
+```
 
-If you need to set any arguments, do so now by running `set args ARGS`, for
-example:
+Set arguments when needed:
 
-    set args -F -k
+```text
+set args -F -k
+```
 
-Now start the program by typing `r`. When the application crashes you will be
-dumped back into the debugger, the application may appear to be frozen. Run
-the following command:
+Start with `run`. After the crash, collect every thread and local variable:
 
-    thread apply all bt
+```text
+thread apply all bt full
+```
 
-Once you have this information please pastebin the log from looking-glass as
-well as the information resulting from this command.
+Provide that output together with the complete client log. Keep
+`looking-glass-client.debug` from the same build; installed builds place it in
+the standard `bin/.debug` location.
 
-## If you're experencing high CPU load and/or poor performance.
+## Hangs or high CPU use
 
-The steps here are identical to the above, except instead of waiting for the
-program to crash, in the debugger press `CTRL+C` while the program is
-exhibiting the problem, then run `thread apply all bt` and pastebin your log
-and the results of the command.
+Run under `gdb` as above. While the fault is visible, press `Ctrl+C` in the
+debugger and collect:
+
+```text
+thread apply all bt full
+```
+
+For an intermittent stall, collect several samples rather than one. Include
+the frame-timing graph when it helps identify the affected stage.
+
+## IDD faults
+
+Use the Windows IDD helper to open
+`C:\ProgramData\Looking Glass (IDD)`. Collect the IDD, input, service and helper
+logs, including rotated `.1` through `.4` files when the fault happened before
+the latest restart. See the end-user IDD diagnostics page for the exact file
+names.

client/src/audio.c

@@ -2305,9 +2305,9 @@ static PlaybackDataResult playbackData(const void * data, size_t frameCount,
   const int maxPeriodFrames =
     max(audio.playback.deviceMaxPeriodFrames, sourceData->devPeriodFrames);
   /* The device period, delivery jitter, packet phase, and resampler delay
-   * define the minimum viable latency. latencyOffset is strictly an additive
-   * user offset over that same minimum for both startup and steady state. */
-  const double latencyOffsetFrames =
+   * define the minimum viable latency. Provider feedback directly controls
+   * the source rate, so latencyOffset only applies to local rate control. */
+  const double latencyOffsetFrames = providerRateControl ? 0.0 :
     max(g_params.audioLatencyOffset, 0) *
       audio.playback.sampleRate / 1000.0;
   const double arrivalReserveFrames =

client/transports/SPICE/spice.c

@@ -86,9 +86,9 @@ static void spiceSetup(void)
     {
       .module       = "spice",
       .name         = "usbAudio",
-      .description  = "Use USB redirection for SPICE audio playback",
+      .description  = "Use the emulated USB audio device",
       .type         = OPTION_TYPE_BOOL,
-      .value.x_bool = false
+      .value.x_bool = true
     },
     {0}
   };