Document unsynchronized HDMI/SDI output.

[nageru-docs] / audio.rst

diff --git a/audio.rst b/audio.rst
index 24c71baba8c5ebf868619323e15c68e34d7905e3..bb6876ecb85f5da3cf9c99a0428ab4ff4025dbf8 100644 (file)
--- a/audio.rst
+++ b/audio.rst
@@ -321,7 +321,7 @@ headroom, while some are much more variable and need tighter settings.
 Nearly at the top (and nearly first in the chain), there's the EQ section. The **lo-cut** is again
 well-known from the simple audio mode (the filter is separate for each
 bus, the cutoff **frequency** is the same across all buses),
-but there's now also a simple **three-band EQ** per bus. Simply ask the speaker
+but there's now also a simple **three-band EQ** per bus. Ask the speaker
 to talk normally for a bit, and tweak the controls until it sounds good.
 People have different voices and different ways of holding the microphone,
 and if you have a reasonable ear, you can use the EQ to your advantage to
@@ -414,7 +414,7 @@ Unless you have a reference sheet for your MIDI controller, specifying which
 controller and number numbers the different physical knobs and faders
 emit, inputting these numbers by hand can be a frustrating procedure.
 (Actually, even with a reference sheet, it probably is.) Thus, the preferred
-way is by autosensing; simply select the given mapping with the mouse
+way is by autosensing; select the given mapping with the mouse
 and use the control you want to bind it to, and Nageru automatically
 fills it in.
 
@@ -464,7 +464,7 @@ same position for the two controllers. (There is a similar problem
 when starting up Nageru for the first time, where the controllers
 are not necessarily in the place matching Nageru's startup settings.)
 Some more expensive controllers support *motorized faders*, where
-the host can simply tell the control to move to the right place
+the host can tell the control to move to the right place
 and thus solve the problem, but Nageru does not currently support them.
 
 .. image:: images/highlight.png