docs: Format consistency, such as representation of program names or filepaths

1 files changed, 16 insertions, 16 deletions

diff --git a/host/docs/general.rst b/host/docs/general.rst
index 02ab26f46..ebba7b532 100644
--- a/host/docs/general.rst
+++ b/host/docs/general.rst
@@ -5,7 +5,7 @@ UHD - General Application Notes
 .. contents:: Table of Contents
 
 ------------------------------------------------------------------------
-Tuning notes
+Tuning Notes
 ------------------------------------------------------------------------
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -20,12 +20,12 @@ In a typical use-case, the user specifies an overall center frequency for the
 signal chain.  The RF front-end will be tuned as close as possible to the center
 frequency, and the DSP will account for the error in tuning between target
 frequency and actual frequency.  The user may also explicitly control both
-stages of tuning through through the tune_request_t object, which allows for
+stages of tuning through through the **tune_request_t** object, which allows for
 more advanced tuning.
 
 In general, Using UHD's advanced tuning is highly recommended as it makes it
 easy to move the DC component out of your band-of-interest.  This can be done by
-passing your desired LO offset to the tune_request_t object, and letting UHD
+passing your desired LO offset to the **tune_request_t** object, and letting UHD
 handle the rest.
 
 Tuning the receive chain:
@@ -69,7 +69,7 @@ Pseudo-code for dealing with settling time after tuning on receive:
     usrp->issue_stream_command(...);
 
 ------------------------------------------------------------------------
-Specifying the subdevice to use
+Specifying the Subdevice to Use
 ------------------------------------------------------------------------
 A subdevice specification string for USRP family devices is composed of:
 
@@ -115,7 +115,7 @@ The frontend names are documented in the
 `Daughterboard Application Notes <./dboards.html>`_
 
 ------------------------------------------------------------------------
-Overflow/Underflow notes
+Overflow/Underflow Notes
 ------------------------------------------------------------------------
 **Note:** The following overflow/underflow notes do not apply to USRP1,
 which does not support the advanced features available in newer products.
@@ -132,26 +132,26 @@ and pushes an inline message packet into the receive stream.
 The host does not back-pressure the receive stream.
 When the kernel's socket buffer becomes full, it will drop subsequent packets.
 UHD detects the overflow as a discontinuity in the packet's sequence numbers,
-and muxes an inline message packet into the receive stream.
+and pushes an inline message packet into the receive stream.
 
 **Other devices**:
 The host back-pressures the receive stream.
 Therefore, overflows always occur in the device itself.
-When the device's internal buffers become full, streaming is shutoff,
+When the device's internal buffers become full, streaming is shut off,
 and an inline message packet is sent to the host.
 If the device was in continuous streaming mode,
-the UHD will automatically restart streaming.
+UHD will automatically restart streaming.
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Underflow notes
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 When transmitting, the device consumes samples at a constant rate.
 Underflow occurs when the host does not produce data fast enough.
-When the UHD detects underflow, it prints an "U" to stdout,
+When UHD detects underflow, it prints a "U" to stdout,
 and pushes a message packet into the async message stream.
 
 ------------------------------------------------------------------------
-Threading notes
+Threading Notes
 ------------------------------------------------------------------------
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -161,7 +161,7 @@ For the most part, UHD is thread-safe.
 Please observe the following limitations:
 
 **Fast-path thread requirements:**
-There are three fast-path methods for a device: send(), recv(), and recv_async_msg().
+There are three fast-path methods for a device: **send()**, **recv()**, and **recv_async_msg()**.
 All three methods are thread-safe and can be called from different thread contexts.
 For performance, the user should call each method from a separate thread context.
 These methods can also be used in a non-blocking fashion by using a timeout of zero.
@@ -169,7 +169,7 @@ These methods can also be used in a non-blocking fashion by using a timeout of z
 **Slow-path thread requirements:**
 It is safe to change multiple settings simultaneously. However,
 this could leave the settings for a device in an uncertain state.
-The is because changing one setting could have an impact on how a call affects other settings.
+This is because changing one setting could have an impact on how a call affects other settings.
 Example: setting the channel mapping affects how the antennas are set.
 It is recommended to use at most one thread context for manipulating device settings.
 
@@ -177,9 +177,9 @@ It is recommended to use at most one thread context for manipulating device sett
 Thread priority scheduling
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-When the UHD spawns a new thread it may try to boost the thread's scheduling priority.
-When setting the priority fails, the UHD prints out an error.
-This error is harmless, it simply means that the thread will have a normal scheduling priority.
+When UHD spawns a new thread it may try to boost the thread's scheduling priority.
+When setting the priority fails, UHD prints out an error.
+This error is harmless; it simply means that the thread will have a normal scheduling priority.
 
 **Linux Notes:**
 
@@ -193,7 +193,7 @@ Replace <my_group> with a group to which your user belongs.
 Settings will not take effect until the user is in a different login session.
 
 ------------------------------------------------------------------------
-Misc notes
+Miscellaneous Notes
 ------------------------------------------------------------------------
 
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^