audiotest: init repo
First file to get the 'audiotest' repository going.
BUG=None
TEST=None
diff --git a/README.txt b/README.txt
new file mode 100644
index 0000000..88e56c7
--- /dev/null
+++ b/README.txt
@@ -0,0 +1,78 @@
+
+ChromeOS Audio Test
+
+This package intends to be a fast and powerful automated audio test tool.
+It performs polyphonic tone synthesis while simultaneously capturing
+the incoming sound in some form of external audio loopback. The
+external Mic/Headphone jack can easily be tested but the built-in
+speakers and microphone can also be tested by placing the
+ChromeBook/Laptop in a box and arranging for the built-in speaker
+sound to bounce off a surface and be directed to the built-in
+microphone. USB/audio dongles can also be tested and the audio output
+present in a HDMI port can likewise be tested with an appropriate
+dongle while looping back to an incoming microphone port.
+
+The incoming sound is convolved through a Fourier Transform and the
+resulting energy peaks are filtered, sorted and compared to the known
+expected tones. Any missing or unexpected tones are reported.
+This test is fast- usually running in 1/2 second per port combination
+tested. During that time up to 7 sinsusoidal tones are polyphonically
+played, captured, Fourier analyzed, a report given and an optional
+spectrogram created. More than 7 tones can be used but peak
+discrimination of the convolved signal becomes more difficult.
+This could be handled by using a larger transform space and taking
+a little more time in processing.
+
+It is a command line tool which lends itself to being
+script driven. Scripts would be different for different
+laptop/chromebook devices as the configuration of audio inputs
+and outputs can be very different across different platforms.
+This tool can be run on any Linux machine, not just a ChromeBook,
+providied the ALSA audio subsystem is available, and it usually will be.
+
+Additional features in the tool:
+- Generation of a captured audio spectrogram file in 'gnuplot' format.
+- Playing the captured sound buffer to a monitor port. Useful when
+ DUT is in a chamber and the monitor port is a USB dongle.
+- Generation of sound without capture; capture without generation.
+ Useful for external characterization of test tool itself.
+
+
+Additional features planned for inclusion very shortly:
+- Automatic test sequencing of multiple channels in a port.
+- Remote control, so a master can test ports in a Device Under Test.
+- Higher resolution sound capture with new hardware.
+
+
+----------------------------------------------------------------------
+Miscellaneous Notes
+
+
+Properties of the DFT
+DFT stands for 'Discrete Fourier Transform'. A pure Fourier
+Transform is continuous; DFTs were invented so Fourier Transforms
+could be used in the real world.
+The reverse of the DFT is calculated simply by applying the
+Fourier transform again, and reversing the resulting buffer
+(to satisfy normalization, also divide resulting samples by N).
+
+The components of the DFT are complex numbers. They have a modulus
+and a phase:
+The modulus of V[k], sqrt(V[k]*V*[k]), describes the intensity of
+the particular frequency corresponding to k (because of normalization,
+divide modulus by sqrt(N))
+
+The phase of a given component describes the phase shift of this
+component--at what angle it starts its oscillations.
+
+What is the relation between k, the index of the Fourier component,
+and its frequency? The function describing the k-th basis vector
+is e-2πikt/N. Sample it at t= 0,1,2,..,N-1. Its real part is
+cos(2πkt/N) (cosine is symmetric, so sign of argument doesn't matter).
+Cosine starts repeating after 2π, which corresponds to
+kt/N = 1 or t = N/k. So how many such repetitions fit in a segment
+of length N? Exactly k. In other words, the k-th basis vector has
+k periods per buffer. What time interval corresponds to one buffer?
+That depends on sampling speed. If sps is number of samples/sec,
+then sps/N is number of buffers/second. Therefore k*sps/N is number
+of periods/second, or frequency.
