OboeTester - improve docs
Explain latency test algorithm.
Encourage playing with "Workload".
diff --git a/apps/OboeTester/docs/Usage.md b/apps/OboeTester/docs/Usage.md
index d334035..f695c5b 100644
--- a/apps/OboeTester/docs/Usage.md
+++ b/apps/OboeTester/docs/Usage.md
@@ -8,11 +8,22 @@
### Test Output
+Tap the green bar to expand the Settings display.
+
Test opening, starting, stopping and closing a stream.
Various stream parameters can be selected before opening.
While the stream is playing, the frame counts and stream state are displayed.
The latency is estimated based on the timestamp information.
+Experiment with changing the buffer size to see if there are glitches when the size is high or low.
+
+Experiment with changing the "Workload".
+Watch the frame counters and the #XRuns.
+The audio is expected to glitch when the workload is high because there is too much work
+and the audio task misses its delivery deadlines.
+
+The extra workload is generated by calculating a random number in a loop and then adding the result to the output at an inaudible level. This technique prevents the compiler optimizer from skipping the work.
+
### Test Input
Test input streams. Displays current volume as VU bars.
@@ -38,27 +49,33 @@
This test copies input to output and adds up to 3 seconds of delay.
This can be used to simulate high latency on a phone that supports low latency.
Try putting the phone to your ear with the added delay at 0 and try talking.
-Then set it to about 100 msec and try talking on the phone. Notice how the echo can be very confusing.
+Then set it to about 1-200 msec and try talking on the phone. Notice how the echo can be very confusing.
### Round Trip Latency
-This test works with either a loopback adapter or through speakers.
+This test works with either a [loopback adapter](https://source.android.com/devices/audio/latency/loopback) or through speakers.
Latency through the speakers will probably be higher.
It measures the input and output latency combined.
Set the volume somewhere in the middle.
+The test works by sending a random series of bits encoded using smoothed Manchester Encoding.
+This signal has a very sharp peak when we correlate output and input.
+So it works at almost any volume. But the confidence will be higher at higher volumes.
+
### Glitch Test
This test works best with a loopback adapter. But it can also work in a quiet room.
It plays a sine wave and then tries to record and lock onto that sine wave.
If the actual input does not match the expected sine wave value then it is counted as a glitch.
The test will display the maximum time that it ran without seeing a glitch.
-A "reset" occurs if there is not enough input data, which causes a gap in the signal.
-Some resets are common at the beginnng.
+
+Look for the #XRuns display.
+If #XRuns increments when a glitch occurs then the glitch is probably due to preemption of the audio task.
+If #XRuns is not incrementing then the glitches may be due to AAudio MMAP tuning errors in the HAL.
### Auto Glitch Test
Measure glitches for various combinations of input and output settings.
Change the test duration to a high value and let it run for a while.
-If you get glitches in one configuration then you can investigate using the Manual Glitch Test.
+If you get glitches in one configuration then you can investigate using the previous manual Glitch Test.
The Share button will let you email the report to yourself.