diff --git a/CAR INSTALL.md b/CAR INSTALL.md
index 879015ade..062b6df52 100644
--- a/CAR INSTALL.md	
+++ b/CAR INSTALL.md	
@@ -19,7 +19,7 @@ In this example, a Raspberry Pi Zero W and a Pimoroni PHAT DAC are used. This co
 ### Prepare the initial SD Image
 * Download the latest version of Raspbian Lite -- Stretch Lite of 2018-03-13 at the time of writing -- and install it onto an SD Card.
 * Mount the card on a Linux machine. Two drives should appear -- a `boot` drive and a `rootfs` drive. Both of these need a little modification.
-* Enable SSH service by creating a file called `ssh` on the `boot` drive. To do this, mount the drive and CD to its `boot` partiton (since my username is `mike`, the drive is at `/media/mike/boot`):
+* Enable SSH service by creating a file called `ssh` on the `boot` drive. To do this, mount the drive and CD to its `boot` partition (since my username is `mike`, the drive is at `/media/mike/boot`):
 ```
 $ touch ssh
 ```
diff --git a/INSTALL.md b/INSTALL.md
index 8d8dc7dfa..a5a61991a 100644
--- a/INSTALL.md
+++ b/INSTALL.md
@@ -2,7 +2,7 @@ Simple Installation Instructions
 ==
 Here are simple instructions for building and installing Shairport Sync on a Raspberry Pi B, 2B, 3B or 3B+. It is assumed that the Pi is running Raspbian Stretch Lite – a GUI isn't needed, since Shairport Sync runs as a daemon program. For a more thorough treatment, please go to the [README.md](https://github.com/mikebrady/shairport-sync/blob/master/README.md#building-and-installing) page.
 
-In the commands below, note the convention that a `#` prompt means you are in superuser mode and a `$` prompt means you are in a regular non-priviliged user mode. You can use `sudo` *("SUperuser DO")* to temporarily promote yourself from user to superuser, if permitted. For example, if you want to execute `apt-get update` in superuser mode and you are in user mode, enter `sudo apt-get update`.
+In the commands below, note the convention that a `#` prompt means you are in superuser mode and a `$` prompt means you are in a regular unprivileged user mode. You can use `sudo` *("SUperuser DO")* to temporarily promote yourself from user to superuser, if permitted. For example, if you want to execute `apt-get update` in superuser mode and you are in user mode, enter `sudo apt-get update`.
 
 ### Configure and Update
 Do the usual update and upgrade:
diff --git a/README-DEVELOPMENT.md b/README-DEVELOPMENT.md
index 233676095..8193f84e4 100644
--- a/README-DEVELOPMENT.md
+++ b/README-DEVELOPMENT.md
@@ -81,7 +81,7 @@ Please refer to the relevant pages for building for the above systems.
 
 **Determine The Configuration Needed**
 
-Shairport Sync has a number of different "backends" that connnect it to the system's audio handling infrastructure. Most recent Linux distributions that have a GUI – including Ubuntu, Debian and others – use PulseAudio to handle sound. In such cases, it is inadvisable to attempt to disable or remove PulseAudio. Thus, if your system uses PulseAudio, you should build Shairport Sync with the PulseAudio backend. You can check to see if PulseAudio is running by opening a Terminal window and entering the command `$ pactl info`. Here is an example of what you'll get if PulseAudio is installed, though the exact details may vary:
+Shairport Sync has a number of different "backends" that connect it to the system's audio handling infrastructure. Most recent Linux distributions that have a GUI – including Ubuntu, Debian and others – use PulseAudio to handle sound. In such cases, it is inadvisable to attempt to disable or remove PulseAudio. Thus, if your system uses PulseAudio, you should build Shairport Sync with the PulseAudio backend. You can check to see if PulseAudio is running by opening a Terminal window and entering the command `$ pactl info`. Here is an example of what you'll get if PulseAudio is installed, though the exact details may vary:
 ```
 $ pactl info
 Server String: unix:/run/user/1000/pulse/native
diff --git a/README.md b/README.md
index 5a7acbe7d..d9976d820 100644
--- a/README.md
+++ b/README.md
@@ -97,7 +97,7 @@ You should also remove the initialisation script files `/etc/systemd/system/shai
 
 **Determine The Configuration Needed**
 
-Shairport Sync has a number of different "backends" that connnect it to the system's audio handling infrastructure. Most recent Linux distributions that have a GUI – including Ubuntu, Debian and others – use PulseAudio to handle sound. In such cases, it is inadvisable to attempt to disable or remove PulseAudio. Thus, if your system uses PulseAudio, you should build Shairport Sync with the PulseAudio backend. You can check to see if PulseAudio is running by opening a Terminal window and entering the command `$ pactl info`. Here is an example of what you'll get if PulseAudio is installed, though the exact details may vary:
+Shairport Sync has a number of different "backends" that connect it to the system's audio handling infrastructure. Most recent Linux distributions that have a GUI – including Ubuntu, Debian and others – use PulseAudio to handle sound. In such cases, it is inadvisable to attempt to disable or remove PulseAudio. Thus, if your system uses PulseAudio, you should build Shairport Sync with the PulseAudio backend. You can check to see if PulseAudio is running by opening a Terminal window and entering the command `$ pactl info`. Here is an example of what you'll get if PulseAudio is installed, though the exact details may vary:
 ```
 $ pactl info
 Server String: unix:/run/user/1000/pulse/native
@@ -609,7 +609,7 @@ This will be followed by the statistics themselves at regular intervals, for exa
 
 "Output frames per second" is the actual rate at which frames of audio are taken by the output device. On a system with a well-conditioned `ntp`-based clock (and without output underruns) this figure should be very accurate after playing material continuously for a period.
 
-"Source clock drift in ppm" is an estimate of the difference in timekeeping between the audio source and the Shairport Sync devive. It is calculated from a linear regression of drift sample data. The number of samples the estimate is based on is given in the next column, "Source clock drift sample count".
+"Source clock drift in ppm" is an estimate of the difference in timekeeping between the audio source and the Shairport Sync device. It is calculated from a linear regression of drift sample data. The number of samples the estimate is based on is given in the next column, "Source clock drift sample count".
 
 "Rough calculated correction in ppm" is a very crude estimate of the amount of interpolation that needs to applied, on average, to keep sync. It is not really to be relied on at this time.
 
diff --git a/RELEASENOTES-DEVELOPMENT.md b/RELEASENOTES-DEVELOPMENT.md
index a5fc6ce84..da976bb92 100644
--- a/RELEASENOTES-DEVELOPMENT.md
+++ b/RELEASENOTES-DEVELOPMENT.md
@@ -90,7 +90,7 @@ Version 3.3d56 to Version 3.3d40
 
 **Enhancements**
 * Changes to the Jack Audio back end. The back end for Jack Audio, `audio_jack.c`,  has been extensively rewritten by [Jörn Nettingsmeier](https://github.com/nettings) in a way that is more in keeping with the Jack Audio style. It uses native Jack Audio lockless buffers and offers autoconnect facilities that the previous version didn't have. Many thanks to him.
-* The volume-control software has been completely rewritten. From a user's point of view, the result should be a much smoother response to volume contol changes, free from artefacts. It is now also possible to combine the hardware mixer and the software attenuator in two ways -- giving priority to the software mixer or giving priority to the hardware mixer. see the new `volume_range_combined_hardware_priority` setting in the `general` section opf the configuration file.
+* The volume-control software has been completely rewritten. From a user's point of view, the result should be a much smoother response to volume control changes, free from artefacts. It is now also possible to combine the hardware mixer and the software attenuator in two ways -- giving priority to the software mixer or giving priority to the hardware mixer. see the new `volume_range_combined_hardware_priority` setting in the `general` section opf the configuration file.
 * The muting/unmuting code has been rewritten to be simpler and more consistent.
 * In the `alsa` backend, new `play()` and `delay()` functions minimise the use of `snd_pcm_recover()` to prevent unnecessary resets of the output DACs.
 * In the `alsa` backend driver, hardware isn't accessed until the first time it is needed. That is, when Shairport Sync starts up, it no longer needs to access the device momentarily. Instead, it waits for the first use.
@@ -378,7 +378,7 @@ Update [TROUBLESHOOTING.md](https://github.com/mikebrady/shairport-sync/blob/dev
 Version 3.2d45
 ====
 **Enhancement**
-* Restore the old method for calculating latency for older AirPlay sources: an AirPlay source displaying an AirPlay User Agent string verion of 353 or older -- corresponding to iOS 11.1.2 or older -- will add an extra 0.25 seconds to the latency requested. This seems to be right.
+* Restore the old method for calculating latency for older AirPlay sources: an AirPlay source displaying an AirPlay User Agent string version of 353 or older -- corresponding to iOS 11.1.2 or older -- will add an extra 0.25 seconds to the latency requested. This seems to be right.
 
 Version 3.2d44
 ====
@@ -398,7 +398,7 @@ Version 3.2d41
 Version 3.2d40
 ====
 **Bug Fixes**
-* A number of serious and long-standing bugs have been identified and fixed in the threads that handle audio, control and timing packets. Specifically, if UDP reception or transmission errors occured (a rare occurence on a good network, but possible on noisy or congested networks), the threads would quit. In this way, an error on the reception of the first control packet could mute an entire play session.
+* A number of serious and long-standing bugs have been identified and fixed in the threads that handle audio, control and timing packets. Specifically, if UDP reception or transmission errors occurred (a rare occurrence on a good network, but possible on noisy or congested networks), the threads would quit. In this way, an error on the reception of the first control packet could mute an entire play session.
 
 **Enhancements**
 * The code used to request the retransmission of missing audio packets has been significantly improved.
@@ -427,7 +427,7 @@ Version 3.2d34
 * `pfls` and `prsm` messages are less frequent, especially when a play session starts.
 
 **Other Developments**
-* Shairport Sync now uses about an extra half megabyte of RAM for compatability with TuneBlade's option to have a very long latency -- up to five seconds.
+* Shairport Sync now uses about an extra half megabyte of RAM for compatibility with TuneBlade's option to have a very long latency -- up to five seconds.
 
 Version 3.2d33
 ====
@@ -437,7 +437,7 @@ Version 3.2d30
 ====
 **Enhancements**
 * A "native" D-Bus Remote Control permits remote control of the current AirPlay or iTunes client. It includes status information about whether the remote control connection is viable or not, i.e. whether it can still be used to control the client.
-A remote control connection to the audio client becomes valid when the client starts AirPlaying to Shairport Sync. The connections remains valid until the audio source deselects Shairport Sync for AirPlay, or until the client disappears, or until another client starts AirPlaying to Shairport Sync. It is likely that a time limit will be put on this, so that after, say, 30 minutes of inactivity, the remote contol connection will be dropped.
+A remote control connection to the audio client becomes valid when the client starts AirPlaying to Shairport Sync. The connections remains valid until the audio source deselects Shairport Sync for AirPlay, or until the client disappears, or until another client starts AirPlaying to Shairport Sync. It is likely that a time limit will be put on this, so that after, say, 30 minutes of inactivity, the remote control connection will be dropped.
 
 Version 3.2d29
 ====
@@ -577,7 +577,7 @@ Shairport Sync is more stable playing audio from YouTube and SoundCloud on the M
 * When you update from a previous version of Shairport Sync, your output device may have been left in a muted state. You should use a command line tool like `alsamixer` or `amixer` to unmute the output device before further use.
 
 **Change of Default**
-* The default value for the `alsa` setting `mute_using_playback_switch` has been changed to `"no"` for compatability with other audio players on the same machine. The reason is that when this setting is set to `"yes"`, the output device will be muted when Shairport Sync releases it. Unfortunately, other audio players using the output device expect it to be unmuted, causing problems. Thanks to [Tim Curtis](https://github.com/moodeaudio) at [Moode Audio](http://moodeaudio.org) and [Peter Pablo](https://github.com/PeterPablo) for clarifying the issue.
+* The default value for the `alsa` setting `mute_using_playback_switch` has been changed to `"no"` for compatibility with other audio players on the same machine. The reason is that when this setting is set to `"yes"`, the output device will be muted when Shairport Sync releases it. Unfortunately, other audio players using the output device expect it to be unmuted, causing problems. Thanks to [Tim Curtis](https://github.com/moodeaudio) at [Moode Audio](http://moodeaudio.org) and [Peter Pablo](https://github.com/PeterPablo) for clarifying the issue.
 
 **Bug Fixes**
 * Fixed bugs that made Shairport Sync drop out or become unavailable when playing YouTube videos, SoundCloud streams etc. from the Mac. Background: there has been a persistent problem with Shairport Sync becoming unavailable after playing, say, a YouTube clip in a browser on the Mac. Shairport Sync 3.1.2 incorporates a change to how certain AirPlay messages are handled. Introduced in nascent form in 3.1.1, further follow-on changes have improved the handling of player lock and have simplified and improved the handling of unexpected loss of connection. Shairport Sync also now works properly with SoundCloud clips played in a browser on the Mac.
@@ -604,7 +604,7 @@ Version 3.1 brings two new backends, optional loudness and convolution filters,
 
 **Pesky Changes You Should Know About**
 * The `audio_backend_buffer_desired_length_in_seconds` and `audio_backend_latency_offset_in_seconds` settings have been moved from individual backend stanzas to the `general` stanza. They now have an effect on every type of backend.
-* If you are using a System V (aka `systemv`) installation, please note that the default location for PID file has moved -- it is now stored at `/var/run/shairport-sync/shairport-sync.pid`. This change is needed to improve security a little and to improve compatability across platforms. If you're not doing anything strange, this should make no difference.
+* If you are using a System V (aka `systemv`) installation, please note that the default location for PID file has moved -- it is now stored at `/var/run/shairport-sync/shairport-sync.pid`. This change is needed to improve security a little and to improve compatibility across platforms. If you're not doing anything strange, this should make no difference.
 
 **Enhancements**
 * Resynchronisation, which happens when the synchronisation is incorrect by more than 50 ms by default, should be a lot less intrusive when it occurs – it should now either insert silence or skip frames, as appropriate. 
@@ -707,7 +707,7 @@ Version 3.0d20 – Development Version
 Note: all Version 3 changes are summarized above.
 
 **Bug Fix**
-* Fix a small and generally silent error in configure.ac so that it only looks for the systemd direcotry if systemd has been chosen. It caused a warning when cross-compiling.
+* Fix a small and generally silent error in configure.ac so that it only looks for the systemd directory if systemd has been chosen. It caused a warning when cross-compiling.
 
 Version 3.0d19 – Development Version
 ----
@@ -850,7 +850,7 @@ The following is a summary of the bug fixes and enhancements since version 2.8.3
 * Metadata can now be provided via UDP -- thanks to [faceless2](https://github.com/faceless2).
 
 * Statistics output is more machine readable -- thanks to [Jörg Krause](https://github.com/joerg-krause)
-* The `shairport-sync.spec` file has been updated for compatability with building Debian packages using `checkinstall` -- thanks to [vru1](https://github.com/vru1).
+* The `shairport-sync.spec` file has been updated for compatibility with building Debian packages using `checkinstall` -- thanks to [vru1](https://github.com/vru1).
 
 Version 2.8.3.11 – Development Version
 ----
@@ -971,13 +971,13 @@ For full details, please refer to the release notes here, back as far as 2.9.1.
 
 Version 2.9.2 – Development Version
 ----
-Version 2.9.2 focusses on further bug fixes and stability improvements.
+Version 2.9.2 focuses on further bug fixes and stability improvements.
 * Enhanced stability: an important bug has been fixed in the handling of missing audio frames – i.e. what happens when a frame of audio is truly missing, after all attempts to fetch it have been unsuccessful. The bug would cause Shairport Sync to do an unnecessary resynchronisation, or, if resync was turned off, to jump out of sync. This is a long-standing bug – thanks to [Jörg Krause](https://github.com/joerg-krause) for identifying it.
 * An extra diagnostic has been added which gives the mean, standard deviation and maximum values for inter-packet reception time on the audio port. It may be useful for exploring line quality.
 
 Version 2.9.1 – Development Version
 ----
-Version 2.9.1 focusses on bug fixes and stability improvements.
+Version 2.9.1 focuses on bug fixes and stability improvements.
 * Stability improvements are concentrated on what happens when a play sessions ends and is followed immediately by a new session. This happens in iOS 9.2 when you click to the next track or to the previous track. It also happens playing YouTube videos when a Mac's System Audio is routed through AirPlay. Thanks to [Tim Curtis](https://github.com/moodeaudio) for help with these issues.
 * A workaround for an apparent flushing issue in TuneBlade has been included. Thanks to [gibman](https://github.com/gibman) for reporting this issue.
 * A number of bug fixes have been made to `configure.ac` – thanks to [Jörg Krause](https://github.com/joerg-krause).
@@ -1056,7 +1056,7 @@ Version 2.7.5 -- Development Version
 Version 2.7.4 -- Development Version
 ----
 **Enhancements**
-* Use the correct method for finding the `systemd` unit path, as recomended by debain maintainers and
+* Use the correct method for finding the `systemd` unit path, as recommended by Debian maintainers and
 http://www.freedesktop.org/software/systemd/man/daemon.html#Installing%20Systemd%20Service%20Files. Thanks to [dantheperson](https://github.com/dantheperson).
 * Rather than hardwire the path `/usr/local/bin` as the path to the shairport-sync executable, the value of `$PREFIX` is now used during configuration. Thanks to [Nick Steel](https://github.com/kingosticks).
 * Add some extra diagnostic messages if the hardware buffer in the DAC is smaller than desired.
@@ -1088,7 +1088,7 @@ Version 2.7.1 -- Development Version
 Version 2.7 -- Development Version
 ----
 **New Features**
-* Extend the volume range for some DACs. Background: some of the cheaper DACS have a very small volume range (that is, the ratio of the highest to the lowest volume, expressed in decibels, is very small). In some really cheap DACs it's only around 30 dB. That means that the difference betweeen the lowest and highest volume settings isn't large enough. With the new feature, if you set the `general` `volume_range_db` to more than the hardware mixer's range, Shairport Sync will combine the hardware mixer's range with a software attenuator to give the desired range. For example, suppose you want a volume range of 70 dB and the hardware mixer offers only 30 dB, then Shairport Sync will make up the other 40 dB with a software attenuator. One drawback is that, when the volume is being changed, there may be a slight delay (0.15 seconds by default) as the audio, whose volume may have been adjusted in software, propagates through the system. Another slight possible drawback is a slightly heavier load on the processor.
+* Extend the volume range for some DACs. Background: some of the cheaper DACS have a very small volume range (that is, the ratio of the highest to the lowest volume, expressed in decibels, is very small). In some really cheap DACs it's only around 30 dB. That means that the difference between the lowest and highest volume settings isn't large enough. With the new feature, if you set the `general` `volume_range_db` to more than the hardware mixer's range, Shairport Sync will combine the hardware mixer's range with a software attenuator to give the desired range. For example, suppose you want a volume range of 70 dB and the hardware mixer offers only 30 dB, then Shairport Sync will make up the other 40 dB with a software attenuator. One drawback is that, when the volume is being changed, there may be a slight delay (0.15 seconds by default) as the audio, whose volume may have been adjusted in software, propagates through the system. Another slight possible drawback is a slightly heavier load on the processor.
 * Check for underflow a little better when buffer aliasing occurs on very bad connections...
 * Add extra debug messages to the alsa back end to diagnose strange DACs.
 * Add configuration file for the `libao` back end -- to change the buffer size and the latency offset, same as for stdout.
@@ -1110,7 +1110,7 @@ This is basically version 2.4.2 with two small fixes. It's been bumped to 2.6 be
 
 Version 2.4.2
 ----
-This release has important enhancements, bug fixes and documentation updates. It also appears to bring compatiblity with Synology NAS devices.
+This release has important enhancements, bug fixes and documentation updates. It also appears to bring compatibility with Synology NAS devices.
 
 
 **New Features**
@@ -1129,7 +1129,7 @@ Using source-specified latencies is now automatic unless non-standard static lat
 * Volume ratios expressed in decibels are now consistently denominated in voltage decibels rather than power decibels. The rationale is that the levels refer to voltage levels, and power is proportional to the square of voltage.
 Thus a ratio of levels of 65535 to 1 is 96.3 dB rather than the 48.15 dB used before.
 * The latency figure returned to the source as part of the response to an rtsp request packet is 11,025, which may (?) be meant to indicate the minimum latency the device is capable of. 
-* An experimental handler for a GET_PARAMETER rtsp request has been added. It does nothing except log the occurence.
+* An experimental handler for a GET_PARAMETER rtsp request has been added. It does nothing except log the occurrence.
 * The RTSP request dispatcher now logs an event whenever an unrecognised rtsp has been made.
 
 
@@ -1141,8 +1141,8 @@ This release has three small bug fixes and some small documentation updates.
 
 Changes from the previous stable version -- 2.4 -- are summarised here:
  * The USE_CUSTOM_LOCAL_STATE_DIR macro was still being used when it should have been USE_CUSTOM_PID_DIR. This could affect users using a custom location for the PID directory.
- * A compiler error has been fixed that occured if metadata was enabled and tinysvcmdns was included.
- * A crash has been fixed that occured if metadata was enabled and a metadata pipename was not specified.
+ * A compiler error has been fixed that occurred if metadata was enabled and tinysvcmdns was included.
+ * A crash has been fixed that occurred if metadata was enabled and a metadata pipe name was not specified.
 (Thanks to the contributors who reported bugs.)
  
 **Small Changes**
@@ -1189,7 +1189,7 @@ Version 2.3.12
 
 
 **Enhancements**
-* Larger range of interpolation. Shairport Sync was previously constrained not to make interpolations ("corrections") of more than about 1 per 1000 frames. This contraint has been relaxed, and it is now able to make corrections of up to 1 in 352 frames. This might result in a faster and undesirably sudden correction early during a play session, so a number of further changes have been made. The full set of these changes is as follows:
+* Larger range of interpolation. Shairport Sync was previously constrained not to make interpolations ("corrections") of more than about 1 per 1000 frames. This constraint has been relaxed, and it is now able to make corrections of up to 1 in 352 frames. This might result in a faster and undesirably sudden correction early during a play session, so a number of further changes have been made. The full set of these changes is as follows:
   * No corrections happen for the first five seconds.
   * Corrections of up to about 1 in 1000 for the next 25 seconds.
   * Corrections of up to 1 in 352 thereafter.
@@ -1208,7 +1208,7 @@ Bug fix
 * The "pipe" backend used output code that would block if the pipe didn't have a reader. This has been replaced by non-blocking code. Here are some implications:
   * When the pipe is created, Shairport Sync will not block if a reader isn't present.
   * If the pipe doesn't have a reader when Shairport Sync wants to output to it, the output will be discarded.
-  * If a reader disappears while writing is occuring, the write will time out after five seconds.
+  * If a reader disappears while writing is occurring, the write will time out after five seconds.
   * Shairport Sync will only close the pipe on termination.
 
 Version 2.3.9
@@ -1285,7 +1285,7 @@ Version 2.3.1
 Some big changes "under the hood" have been made, leading to limited support for unsynchronised output to `stdout` or to a named pipe and continuation of defacto support for unsynchronised PulseAudio. Also, support for a configuration file in preference to command line options, an option to ignore volume control and other improvements are provided.
 
 In this release, Shairport Sync gains the ability to read settings from `/etc/shairport-sync.conf`.
-This gives more flexibility in adding features gives better compatability across different versions of Linux.
+This gives more flexibility in adding features gives better compatibility across different versions of Linux.
 Existing command-line options continue to work, but some will be deprecated and may disappear in a future version of Shairport Sync. New settings will only be available via the configuration file.
 
 Note that, for the present, settings in the configuration will have priority over command line options for Shairport Sync itself, in contravention of the normal unix convention. Audio back end command line options, i.e. those after the `--`, have priority over configuration file settings for the audio backends.
@@ -1363,7 +1363,7 @@ Version 2.2
 -----
 * Enhancements:
  * New password option: `--password=SECRET`
- * New tolerance option: `--tolerance=FRAMES`. Use this option to specify the largest synchronisation error to allow before making corrections. The default is 88 frames, i.e. 2 milliseconds. The default tolerance is fine for streaming over wired ethernet; however, if some of the stream's path is via WiFi, or if the source is a third-party product, it may lead to much overcorrection -- i.e. the difference between "corrections" and "net correction" in the `--statistics` option. Increasing the tolerence may reduce the amount of overcorrection.
+ * New tolerance option: `--tolerance=FRAMES`. Use this option to specify the largest synchronisation error to allow before making corrections. The default is 88 frames, i.e. 2 milliseconds. The default tolerance is fine for streaming over wired ethernet; however, if some of the stream's path is via WiFi, or if the source is a third-party product, it may lead to much overcorrection -- i.e. the difference between "corrections" and "net correction" in the `--statistics` option. Increasing the tolerance may reduce the amount of overcorrection.
 
 Version 2.1.15
 -----
@@ -1418,7 +1418,7 @@ With this feature, you can allow Shairport Sync always to advertise and provide
 	
 * Annoying things you should know about if you're updating from a previous version:
 	* Options `--with-openssl`, `--with-polarssl` have been replaced with a new option `--with-ssl=<option>` where `<option>` is either `openssl` or `polarssl`.
-	* Option `--with-localstatedir` has been replaced with `--with-piddir`. This compilation option allows you to specify the directory in which the PID file will be written. The directory must exist and be writable. Supercedes the `--with-localstatedir` and describes the intended functionality a little more accurately.
+	* Option `--with-localstatedir` has been replaced with `--with-piddir`. This compilation option allows you to specify the directory in which the PID file will be written. The directory must exist and be writable. Supersedes the `--with-localstatedir` and describes the intended functionality a little more accurately.
 
 * Bugfixes
 	* A small (?) bug in the flush logic has been corrected. Not causing any known problem.
diff --git a/RELEASENOTES.md b/RELEASENOTES.md
index 2e97e7476..93daee34a 100644
--- a/RELEASENOTES.md
+++ b/RELEASENOTES.md
@@ -130,7 +130,7 @@ Version 3.2RC2
 Version 3.2RC1
 ====
 **Enhancements**
-* Shairport Sync now offers an IPC interface via D-Bus. It provides an incomplete but functional MPRIS interface and also provides a native Shairport Sync interface. Both provide some metadata and some remote control. The native D-Bus interface permits remote control of the current AirPlay or iTunes client. It includes status information about whether the remote control connection is viable or not, i.e. whether it can still be used to control the client. A remote control connection to the audio client becomes valid when the client starts AirPlaying to Shairport Sync. The connections remains valid until the audio source deselects Shairport Sync for AirPlay, or until the client disappears, or until another client starts AirPlaying to Shairport Sync. After 15 minutes of inactivity, the remote contol connection will be dropped. 
+* Shairport Sync now offers an IPC interface via D-Bus. It provides an incomplete but functional MPRIS interface and also provides a native Shairport Sync interface. Both provide some metadata and some remote control. The native D-Bus interface permits remote control of the current AirPlay or iTunes client. It includes status information about whether the remote control connection is viable or not, i.e. whether it can still be used to control the client. A remote control connection to the audio client becomes valid when the client starts AirPlaying to Shairport Sync. The connections remains valid until the audio source deselects Shairport Sync for AirPlay, or until the client disappears, or until another client starts AirPlaying to Shairport Sync. After 15 minutes of inactivity, the remote control connection will be dropped.
 * OpenBSD compatibility. Shairport Sync now compiles on OpenBSD -- please consult the OpenBSD note for details.
 * A new `general` option `volume_control_profile`, for advanced use only, with two options: `"standard"` which uses the standard volume control profile -- this has a higher transfer profile at low volumes and a lower transfer profile at high volumes --  or `"flat"` which uses a uniform transfer profile to linearly scale the output mixer's dB according to the AirPlay volume.
 * Some DACs have a feature that the lowest permissible "attenuation" value that the built-in hardware mixer can be set to is not an attenuation value at all – it is in fact a command to mute the output completely. Shairport Sync has always checked for this feature, basically in order to ignore it when getting the true range of attenuation values offered by the mixer.
@@ -154,7 +154,7 @@ However, with this enhancement, Shairport Sync can actually use this feature to
 **Other Changes**
 * `clip` and `svip` metadata messages are now only generated for a play connection, not for all connections (e.g. connections that just enquire if the service is present).
 * `pfls` and `prsm` metadata messages are less frequent, especially when a play session starts.
-* Shairport Sync now uses about an extra half megabyte of RAM for compatability with TuneBlade's option to have a very long latency -- up to five seconds.
+* Shairport Sync now uses about an extra half megabyte of RAM for compatibility with TuneBlade's option to have a very long latency -- up to five seconds.
 * Only ask for missing packets to be resent once, and if any error occurs making the request, stop for 10 seconds.
 * Include the `-pthread` flag -- including the pthread library with `-lpthread` isn't always enough.
 * Add optional timing annotations to debug messages -- see the new settings in the diagnostic stanza of the configuration file.
@@ -171,7 +171,7 @@ Version 3.1.7
 * Stable 3.1.5 and 3.1.6 skipped to synchronise the shairport-sync.spec file contents with the release.
 
 **Enhancement**
-* The metdata output stream can include a `dapo` message carrying the DACP port number to be used when communicating with the DACP remote control. This might be useful because the port number is actually pretty hard to find and requires the use of asynchronous mdns operations. You must be using the Avahi mdns back end.
+* The metadata output stream can include a `dapo` message carrying the DACP port number to be used when communicating with the DACP remote control. This might be useful because the port number is actually pretty hard to find and requires the use of asynchronous mdns operations. You must be using the Avahi mdns back end.
 
 Version 3.1.4
 ====
@@ -203,7 +203,7 @@ Shairport Sync is more stable playing audio from YouTube and SoundCloud on the M
 * When you update from a previous version of Shairport Sync, your output device may have been left in a muted state. You should use a command line tool like `alsamixer` or `amixer` to unmute the output device before further use.
 
 **Change of Default**
-* The default value for the `alsa` setting `mute_using_playback_switch` has been changed to `"no"` for compatability with other audio players on the same machine. The reason is that when this setting is set to `"yes"`, the output device will be muted when Shairport Sync releases it. Unfortunately, other audio players using the output device expect it to be unmuted, causing problems. Thanks to [Tim Curtis](https://github.com/moodeaudio) at [Moode Audio](http://moodeaudio.org) and [Peter Pablo](https://github.com/PeterPablo) for clarifying the issue.
+* The default value for the `alsa` setting `mute_using_playback_switch` has been changed to `"no"` for compatibility with other audio players on the same machine. The reason is that when this setting is set to `"yes"`, the output device will be muted when Shairport Sync releases it. Unfortunately, other audio players using the output device expect it to be unmuted, causing problems. Thanks to [Tim Curtis](https://github.com/moodeaudio) at [Moode Audio](http://moodeaudio.org) and [Peter Pablo](https://github.com/PeterPablo) for clarifying the issue.
 
 **Bug Fixes**
 * Fixed bugs that made Shairport Sync drop out or become unavailable when playing YouTube videos, SoundCloud streams etc. from the Mac. Background: there has been a persistent problem with Shairport Sync becoming unavailable after playing, say, a YouTube clip in a browser on the Mac. Shairport Sync 3.1.2 incorporates a change to how certain AirPlay messages are handled. Introduced in nascent form in 3.1.1, further follow-on changes have improved the handling of player lock and have simplified and improved the handling of unexpected loss of connection. Shairport Sync also now works properly with SoundCloud clips played in a browser on the Mac.
@@ -230,7 +230,7 @@ Version 3.1 brings two new backends, optional loudness and convolution filters,
 
 **Pesky Changes You Should Know About**
 * The `audio_backend_buffer_desired_length_in_seconds` and `audio_backend_latency_offset_in_seconds` settings have been moved from individual backend stanzas to the `general` stanza. They now have an effect on every type of backend.
-* If you are using a System V (aka `systemv`) installation, please note that the default location for PID file has moved -- it is now stored at `/var/run/shairport-sync/shairport-sync.pid`. This change is needed to improve security a little and to improve compatability across platforms. If you're not doing anything strange, this should make no difference.
+* If you are using a System V (aka `systemv`) installation, please note that the default location for PID file has moved -- it is now stored at `/var/run/shairport-sync/shairport-sync.pid`. This change is needed to improve security a little and to improve compatibility across platforms. If you're not doing anything strange, this should make no difference.
 
 **Enhancements**
 * Resynchronisation, which happens when the synchronisation is incorrect by more than 50 ms by default, should be a lot less intrusive when it occurs – it should now either insert silence or skip frames, as appropriate. 
@@ -332,7 +332,7 @@ Version 3.0d20 – Development Version
 Note: all Version 3 changes are summarized above.
 
 **Bug Fix**
-* Fix a small and generally silent error in configure.ac so that it only looks for the systemd direcotry if systemd has been chosen. It caused a warning when cross-compiling.
+* Fix a small and generally silent error in configure.ac so that it only looks for the systemd directory if systemd has been chosen. It caused a warning when cross-compiling.
 
 Version 3.0d19 – Development Version
 ----
@@ -475,7 +475,7 @@ The following is a summary of the bug fixes and enhancements since version 2.8.3
 * Metadata can now be provided via UDP -- thanks to [faceless2](https://github.com/faceless2).
 
 * Statistics output is more machine readable -- thanks to [Jörg Krause](https://github.com/joerg-krause)
-* The `shairport-sync.spec` file has been updated for compatability with building Debian packages using `checkinstall` -- thanks to [vru1](https://github.com/vru1).
+* The `shairport-sync.spec` file has been updated for compatibility with building Debian packages using `checkinstall` -- thanks to [vru1](https://github.com/vru1).
 
 Version 2.8.3.11 – Development Version
 ----
@@ -596,13 +596,13 @@ For full details, please refer to the release notes here, back as far as 2.9.1.
 
 Version 2.9.2 – Development Version
 ----
-Version 2.9.2 focusses on further bug fixes and stability improvements.
+Version 2.9.2 focuses on further bug fixes and stability improvements.
 * Enhanced stability: an important bug has been fixed in the handling of missing audio frames – i.e. what happens when a frame of audio is truly missing, after all attempts to fetch it have been unsuccessful. The bug would cause Shairport Sync to do an unnecessary resynchronisation, or, if resync was turned off, to jump out of sync. This is a long-standing bug – thanks to [Jörg Krause](https://github.com/joerg-krause) for identifying it.
 * An extra diagnostic has been added which gives the mean, standard deviation and maximum values for inter-packet reception time on the audio port. It may be useful for exploring line quality.
 
 Version 2.9.1 – Development Version
 ----
-Version 2.9.1 focusses on bug fixes and stability improvements.
+Version 2.9.1 focuses on bug fixes and stability improvements.
 * Stability improvements are concentrated on what happens when a play sessions ends and is followed immediately by a new session. This happens in iOS 9.2 when you click to the next track or to the previous track. It also happens playing YouTube videos when a Mac's System Audio is routed through AirPlay. Thanks to [Tim Curtis](https://github.com/moodeaudio) for help with these issues.
 * A workaround for an apparent flushing issue in TuneBlade has been included. Thanks to [gibman](https://github.com/gibman) for reporting this issue.
 * A number of bug fixes have been made to `configure.ac` – thanks to [Jörg Krause](https://github.com/joerg-krause).
@@ -681,7 +681,7 @@ Version 2.7.5 -- Development Version
 Version 2.7.4 -- Development Version
 ----
 **Enhancements**
-* Use the correct method for finding the `systemd` unit path, as recomended by debain maintainers and
+* Use the correct method for finding the `systemd` unit path, as recommended by Debian maintainers and
 http://www.freedesktop.org/software/systemd/man/daemon.html#Installing%20Systemd%20Service%20Files. Thanks to [dantheperson](https://github.com/dantheperson).
 * Rather than hardwire the path `/usr/local/bin` as the path to the shairport-sync executable, the value of `$PREFIX` is now used during configuration. Thanks to [Nick Steel](https://github.com/kingosticks).
 * Add some extra diagnostic messages if the hardware buffer in the DAC is smaller than desired.
@@ -713,7 +713,7 @@ Version 2.7.1 -- Development Version
 Version 2.7 -- Development Version
 ----
 **New Features**
-* Extend the volume range for some DACs. Background: some of the cheaper DACS have a very small volume range (that is, the ratio of the highest to the lowest volume, expressed in decibels, is very small). In some really cheap DACs it's only around 30 dB. That means that the difference betweeen the lowest and highest volume settings isn't large enough. With the new feature, if you set the `general` `volume_range_db` to more than the hardware mixer's range, Shairport Sync will combine the hardware mixer's range with a software attenuator to give the desired range. For example, suppose you want a volume range of 70 dB and the hardware mixer offers only 30 dB, then Shairport Sync will make up the other 40 dB with a software attenuator. One drawback is that, when the volume is being changed, there may be a slight delay (0.15 seconds by default) as the audio, whose volume may have been adjusted in software, propagates through the system. Another slight possible drawback is a slightly heavier load on the processor.
+* Extend the volume range for some DACs. Background: some of the cheaper DACS have a very small volume range (that is, the ratio of the highest to the lowest volume, expressed in decibels, is very small). In some really cheap DACs it's only around 30 dB. That means that the difference between the lowest and highest volume settings isn't large enough. With the new feature, if you set the `general` `volume_range_db` to more than the hardware mixer's range, Shairport Sync will combine the hardware mixer's range with a software attenuator to give the desired range. For example, suppose you want a volume range of 70 dB and the hardware mixer offers only 30 dB, then Shairport Sync will make up the other 40 dB with a software attenuator. One drawback is that, when the volume is being changed, there may be a slight delay (0.15 seconds by default) as the audio, whose volume may have been adjusted in software, propagates through the system. Another slight possible drawback is a slightly heavier load on the processor.
 * Check for underflow a little better when buffer aliasing occurs on very bad connections...
 * Add extra debug messages to the alsa back end to diagnose strange DACs.
 * Add configuration file for the `libao` back end -- to change the buffer size and the latency offset, same as for stdout.
@@ -735,7 +735,7 @@ This is basically version 2.4.2 with two small fixes. It's been bumped to 2.6 be
 
 Version 2.4.2
 ----
-This release has important enhancements, bug fixes and documentation updates. It also appears to bring compatiblity with Synology NAS devices.
+This release has important enhancements, bug fixes and documentation updates. It also appears to bring compatibility with Synology NAS devices.
 
 
 **New Features**
@@ -754,7 +754,7 @@ Using source-specified latencies is now automatic unless non-standard static lat
 * Volume ratios expressed in decibels are now consistently denominated in voltage decibels rather than power decibels. The rationale is that the levels refer to voltage levels, and power is proportional to the square of voltage.
 Thus a ratio of levels of 65535 to 1 is 96.3 dB rather than the 48.15 dB used before.
 * The latency figure returned to the source as part of the response to an rtsp request packet is 11,025, which may (?) be meant to indicate the minimum latency the device is capable of. 
-* An experimental handler for a GET_PARAMETER rtsp request has been added. It does nothing except log the occurence.
+* An experimental handler for a GET_PARAMETER rtsp request has been added. It does nothing except log the occurrence.
 * The RTSP request dispatcher now logs an event whenever an unrecognised rtsp has been made.
 
 
@@ -766,8 +766,8 @@ This release has three small bug fixes and some small documentation updates.
 
 Changes from the previous stable version -- 2.4 -- are summarised here:
  * The USE_CUSTOM_LOCAL_STATE_DIR macro was still being used when it should have been USE_CUSTOM_PID_DIR. This could affect users using a custom location for the PID directory.
- * A compiler error has been fixed that occured if metadata was enabled and tinysvcmdns was included.
- * A crash has been fixed that occured if metadata was enabled and a metadata pipename was not specified.
+ * A compiler error has been fixed that occurred if metadata was enabled and tinysvcmdns was included.
+ * A crash has been fixed that occurred if metadata was enabled and a metadata pipe name was not specified.
 (Thanks to the contributors who reported bugs.)
  
 **Small Changes**
@@ -814,7 +814,7 @@ Version 2.3.12
 
 
 **Enhancements**
-* Larger range of interpolation. Shairport Sync was previously constrained not to make interpolations ("corrections") of more than about 1 per 1000 frames. This contraint has been relaxed, and it is now able to make corrections of up to 1 in 352 frames. This might result in a faster and undesirably sudden correction early during a play session, so a number of further changes have been made. The full set of these changes is as follows:
+* Larger range of interpolation. Shairport Sync was previously constrained not to make interpolations ("corrections") of more than about 1 per 1000 frames. This constraint has been relaxed, and it is now able to make corrections of up to 1 in 352 frames. This might result in a faster and undesirably sudden correction early during a play session, so a number of further changes have been made. The full set of these changes is as follows:
   * No corrections happen for the first five seconds.
   * Corrections of up to about 1 in 1000 for the next 25 seconds.
   * Corrections of up to 1 in 352 thereafter.
@@ -833,7 +833,7 @@ Bug fix
 * The "pipe" backend used output code that would block if the pipe didn't have a reader. This has been replaced by non-blocking code. Here are some implications:
   * When the pipe is created, Shairport Sync will not block if a reader isn't present.
   * If the pipe doesn't have a reader when Shairport Sync wants to output to it, the output will be discarded.
-  * If a reader disappears while writing is occuring, the write will time out after five seconds.
+  * If a reader disappears while writing is occurring, the write will time out after five seconds.
   * Shairport Sync will only close the pipe on termination.
 
 Version 2.3.9
@@ -910,7 +910,7 @@ Version 2.3.1
 Some big changes "under the hood" have been made, leading to limited support for unsynchronised output to `stdout` or to a named pipe and continuation of defacto support for unsynchronised PulseAudio. Also, support for a configuration file in preference to command line options, an option to ignore volume control and other improvements are provided.
 
 In this release, Shairport Sync gains the ability to read settings from `/etc/shairport-sync.conf`.
-This gives more flexibility in adding features gives better compatability across different versions of Linux.
+This gives more flexibility in adding features gives better compatibility across different versions of Linux.
 Existing command-line options continue to work, but some will be deprecated and may disappear in a future version of Shairport Sync. New settings will only be available via the configuration file.
 
 Note that, for the present, settings in the configuration will have priority over command line options for Shairport Sync itself, in contravention of the normal unix convention. Audio back end command line options, i.e. those after the `--`, have priority over configuration file settings for the audio backends.
@@ -988,7 +988,7 @@ Version 2.2
 -----
 * Enhancements:
  * New password option: `--password=SECRET`
- * New tolerance option: `--tolerance=FRAMES`. Use this option to specify the largest synchronisation error to allow before making corrections. The default is 88 frames, i.e. 2 milliseconds. The default tolerance is fine for streaming over wired ethernet; however, if some of the stream's path is via WiFi, or if the source is a third-party product, it may lead to much overcorrection -- i.e. the difference between "corrections" and "net correction" in the `--statistics` option. Increasing the tolerence may reduce the amount of overcorrection.
+ * New tolerance option: `--tolerance=FRAMES`. Use this option to specify the largest synchronisation error to allow before making corrections. The default is 88 frames, i.e. 2 milliseconds. The default tolerance is fine for streaming over wired ethernet; however, if some of the stream's path is via WiFi, or if the source is a third-party product, it may lead to much overcorrection -- i.e. the difference between "corrections" and "net correction" in the `--statistics` option. Increasing the tolerance may reduce the amount of overcorrection.
 
 Version 2.1.15
 -----
@@ -1043,7 +1043,7 @@ With this feature, you can allow Shairport Sync always to advertise and provide
 	
 * Annoying things you should know about if you're updating from a previous version:
 	* Options `--with-openssl`, `--with-polarssl` have been replaced with a new option `--with-ssl=<option>` where `<option>` is either `openssl` or `polarssl`.
-	* Option `--with-localstatedir` has been replaced with `--with-piddir`. This compilation option allows you to specify the directory in which the PID file will be written. The directory must exist and be writable. Supercedes the `--with-localstatedir` and describes the intended functionality a little more accurately.
+	* Option `--with-localstatedir` has been replaced with `--with-piddir`. This compilation option allows you to specify the directory in which the PID file will be written. The directory must exist and be writable. Supersedes the `--with-localstatedir` and describes the intended functionality a little more accurately.
 
 * Bugfixes
 	* A small (?) bug in the flush logic has been corrected. Not causing any known problem.
diff --git a/TROUBLESHOOTING.md b/TROUBLESHOOTING.md
index 262bca6ba..8a4e14e54 100644
--- a/TROUBLESHOOTING.md
+++ b/TROUBLESHOOTING.md
@@ -188,7 +188,7 @@ card 1: MP3 [Sound Blaster MP3+], device 0: USB Audio [USB Audio]
   Subdevice #0: subdevice #0
 ````
 
-or look at your exisiting '/etc/asound.conf' file, which may look something like this
+or look at your existing '/etc/asound.conf' file, which may look something like this
 
 ````
 pcm.!default {
diff --git a/activity_monitor.c b/activity_monitor.c
index 544f0362a..bcc25d245 100644
--- a/activity_monitor.c
+++ b/activity_monitor.c
@@ -123,7 +123,7 @@ void activity_monitor_signify_activity(int active) {
   // execute the going_inactive() function.
   //
   // The reason for all this is that we might want to perform the attached scripts
-  // and wait for them to complete before continuing. If they were perfomed in the
+  // and wait for them to complete before continuing. If they were performed in the
   // activity monitor thread, then we couldn't wait for them to complete.
 
   // Thus, the only time the thread will execute a going_... function is when a non-zero
diff --git a/alac.h b/alac.h
index a56c29f1e..33a35928a 100644
--- a/alac.h
+++ b/alac.h
@@ -13,7 +13,7 @@ void alac_free(alac_file *alac);
 
 struct alac_file {
   unsigned char *input_buffer;
-  int input_buffer_bitaccumulator; /* used so we can do arbitary
+  int input_buffer_bitaccumulator; /* used so we can do arbitrary
                                       bit reads */
 
   int samplesize;
diff --git a/audio.c b/audio.c
index cd3f2cb2c..c71ac939a 100644
--- a/audio.c
+++ b/audio.c
@@ -157,7 +157,7 @@ void parse_general_audio_options(void) {
       }
     }
 
-    /* Get the minumum buffer size for fancy interpolation setting in seconds. */
+    /* Get the minimum buffer size for fancy interpolation setting in seconds. */
     if (config_lookup_float(config.cfg,
                             "general.audio_backend_buffer_interpolation_threshold_in_seconds",
                             &dvalue)) {
diff --git a/audio_alsa.c b/audio_alsa.c
index 69aaa0a31..454d27ff8 100644
--- a/audio_alsa.c
+++ b/audio_alsa.c
@@ -73,7 +73,7 @@ int mute(int do_mute); // returns true if it actually is allowed to use the mute
 static double set_volume;
 static int output_method_signalled = 0; // for reporting whether it's using mmap or not
 int delay_type_notified = -1; // for controlling the reporting of whether the output device can do
-                              // precison delays (e.g. alsa->pulsaudio virtual devices can't)
+                              // precision delays (e.g. alsa->pulsaudio virtual devices can't)
 int use_monotonic_clock = 0;  // this value will be set when the hardware is initialised
 
 audio_output audio_alsa = {
diff --git a/audio_jack.c b/audio_jack.c
index 83398e2c5..0aff5025a 100644
--- a/audio_jack.c
+++ b/audio_jack.c
@@ -229,7 +229,7 @@ int jack_init(__attribute__((unused)) int argc, __attribute__((unused)) char **a
   if (jack_activate(client)) {
     die("Could not activate %s JACK client.", config.jack_client_name);
   } else {
-    debug(2, "JACK client %s activated sucessfully.", config.jack_client_name);
+    debug(2, "JACK client %s activated successfully.", config.jack_client_name);
   }
   if (config.jack_autoconnect_pattern != NULL) {
     inform("config.jack_autoconnect_pattern is %s. If you see the program die after this,"
@@ -257,7 +257,7 @@ int jack_init(__attribute__((unused)) int argc, __attribute__((unused)) char **a
             // success
             break;
           default:
-            warn("JACK error no. %d occured while trying to connect %s to %s.", err,
+            warn("JACK error no. %d occurred while trying to connect %s to %s.", err,
                  full_port_name[i], port_list[i]);
             break;
           }
diff --git a/audio_sndio.c b/audio_sndio.c
index 54e1763d8..9fd497ace 100644
--- a/audio_sndio.c
+++ b/audio_sndio.c
@@ -256,7 +256,7 @@ static int delay(long *_delay) {
   pthread_mutex_lock(&sndio_mutex);
   size_t estimated_extra_frames_output = 0;
   if (at_least_one_onmove_cb_seen) { // when output starts, the onmove_cb callback will be made
-    // calculate the difference in time between now and when the last callback occoured,
+    // calculate the difference in time between now and when the last callback occurred,
     // and use it to estimate the frames that would have been output
     uint64_t time_difference = get_absolute_time_in_fp() - time_of_last_onmove_cb;
     uint64_t frame_difference = time_difference * par.rate;
diff --git a/common.h b/common.h
index e9ec58c51..e1b18d88d 100644
--- a/common.h
+++ b/common.h
@@ -148,13 +148,13 @@ typedef struct {
   int volume_max_db;
   int no_sync;            // disable synchronisation, even if it's available
   int no_mmap;            // disable use of mmap-based output, even if it's available
-  double resyncthreshold; // if it get's out of whack my more than this number of seconds, resync.
+  double resyncthreshold; // if it gets out of whack my more than this number of seconds, resync.
                           // Zero means never
                           // resync.
   int allow_session_interruption;
   int timeout; // while in play mode, exit if no packets of audio come in for more than this number
                // of seconds . Zero means never exit.
-  int dont_check_timeout; // this is used to maintain backward compatability with the old -t option
+  int dont_check_timeout; // this is used to maintain backward compatibility with the old -t option
                           // behaviour; only set by -t 0, cleared by everything else
   char *output_name;
   audio_output *output;
@@ -194,7 +194,7 @@ typedef struct {
   char *configfile;
   char *regtype; // The regtype is the service type followed by the protocol, separated by a dot, by
                  // default “_raop._tcp.”.
-  char *interface;     // a string containg the interface name, or NULL if nothing specified
+  char *interface;     // a string containing the interface name, or NULL if nothing specified
   int interface_index; // only valid if the interface string is non-NULL
   double audio_backend_buffer_desired_length; // this will be the length in seconds of the
                                               // audio backend buffer -- the DAC buffer for ALSA
diff --git a/dbus-service.c b/dbus-service.c
index e18a35116..8ab4cd2c0 100644
--- a/dbus-service.c
+++ b/dbus-service.c
@@ -410,10 +410,10 @@ gboolean notify_loudness_threshold_callback(ShairportSync *skeleton,
                                             __attribute__((unused)) gpointer user_data) {
   gdouble th = shairport_sync_get_loudness_threshold(skeleton);
   if ((th <= 0.0) && (th >= -100.0)) {
-    debug(1, ">> setting loudness threshhold to %f.", th);
+    debug(1, ">> setting loudness threshold to %f.", th);
     config.loudness_reference_volume_db = th;
   } else {
-    debug(1, ">> invalid loudness threshhold: %f. Ignored.", th);
+    debug(1, ">> invalid loudness threshold: %f. Ignored.", th);
     shairport_sync_set_loudness_threshold(skeleton, config.loudness_reference_volume_db);
   }
   return TRUE;
diff --git a/man/shairport-sync.7 b/man/shairport-sync.7
index 01163330a..9048b5510 100644
--- a/man/shairport-sync.7
+++ b/man/shairport-sync.7
@@ -29,7 +29,7 @@ You should use the configuration file for setting up Shairport Sync. This file i
 
 (Note: Shairport Sync may have been compiled to use a different configuration directory. You can determine which by performing the command \fI$ shairport-sync -V\f1. One of the items in the output string is the value of the \fBsysconfdir\f1, i.e. the System Configuration Directory.)
 
-Within the configuraton file, settings are organised into groups, for example, there is a "general" group of standard settings, and there is an "alsa" group with settings that pertain to the ALSA back end. Here is an example of a typical configuration file:
+Within the configuration file, settings are organised into groups, for example, there is a "general" group of standard settings, and there is an "alsa" group with settings that pertain to the ALSA back end. Here is an example of a typical configuration file:
 
 \fBgeneral = {\f1
 
@@ -90,7 +90,7 @@ Use this to specify the \fIportnumber\f1 shairport-sync uses to listen for servi
 When shairport-sync starts to play audio, it establises three UDP connections to the audio source. Use this setting to specify the starting \fIportnumber\f1 for these three ports. It will pick the first three unused ports starting from \fIportnumber\f1. The default is port 6001.
 .TP
 \fBudp_port_range=\f1\fIrange\f1\fB;\f1
-Use this in conjunction with the prevous setting to specify the \fIrange\f1 of ports that can be checked for availability. Only three ports are needed. The default is 100, thus 100 ports will be checked from port 6001 upwards until three are found.
+Use this in conjunction with the previous setting to specify the \fIrange\f1 of ports that can be checked for availability. Only three ports are needed. The default is 100, thus 100 ports will be checked from port 6001 upwards until three are found.
 .TP
 \fBdrift_tolerance_in_seconds=\f1\fIseconds\f1\fB;\f1
 Allow playback to drift up to \fIseconds\f1 out of exact synchronization before attempting to correct it. The default is 0.002 seconds, i.e. 2 milliseconds. The smaller the tolerance, the more likely it is that overcorrection will occur. Overcorrection is when more corrections (insertions and deletions) are made than are strictly necessary to keep the stream in sync. Use the \fBstatistics\f1 setting to monitor correction levels. Corrections should not greatly exceed net corrections. This setting replaces the deprecated \fBdrift\f1 setting. 
@@ -140,7 +140,7 @@ The \fImode\f1 can be "stereo", "mono", "reverse stereo", "both left" or "both r
 This can be "hammerton" or "apple". This advanced setting allows you to choose the original Shairport decoder by David Hammerton or the Apple Lossless Audio Codec (ALAC) decoder written by Apple. Shairport Sync must have been compiled with the configuration setting "--with-apple-alac" and the Apple ALAC decoder library must be present for this to work.
 .TP
 \fBinterface=\f1\fI"name"\f1\fB;\f1
-Use this advanced setting if you want to confine Shairport Sync to the named interface. Leave it commented out to get the default bahaviour.
+Use this advanced setting if you want to confine Shairport Sync to the named interface. Leave it commented out to get the default behaviour.
 .TP
 \fBaudio_backend_latency_offset_in_seconds=\f1 \fIoffset_in_seconds\f1\fB;\f1
 Set this \fIoffset_in_seconds\f1 to compensate for a fixed delay in the audio back end. For example, if the output device delays by 100 ms, set this to -0.1.
@@ -225,7 +225,7 @@ Use this setting to specify the format that should be used to send data to the A
 
 "S" means signed; "U" means unsigned; BE means big-endian and LE means little-endian. Except where stated (using *LE or *BE), endianness matches that of the processor. The default is "S16".
 
-If you are using a hardware mixer, the best setting is S16, as audio will pass through Shairport Sync unmodifed except for interpolation. If you are using the software mixer, use 32- or 24-bit, if your device is capable of it, to get the lowest possible levels of dither. 
+If you are using a hardware mixer, the best setting is S16, as audio will pass through Shairport Sync unmodified except for interpolation. If you are using the software mixer, use 32- or 24-bit, if your device is capable of it, to get the lowest possible levels of dither. 
 .TP
 \fBdisable_synchronization=\f1\fI"no"\f1\fB;\f1
 This is an advanced setting and is for debugging only. Set to \fI"yes"\f1 to disable synchronization. Default is \fI"no"\f1. If you use it to disable synchronisation, then sooner or later you'll experience audio glitches due to audio buffer overflow or underflow. 
diff --git a/man/shairport-sync.7.xml b/man/shairport-sync.7.xml
index 199e97fd8..93b24146d 100644
--- a/man/shairport-sync.7.xml
+++ b/man/shairport-sync.7.xml
@@ -111,7 +111,7 @@
 	  i.e. the System Configuration Directory.)</p>
 	  
 	  
-	  <p>Within the configuraton file, settings are organised into <i>groups</i>, for 
+	  <p>Within the configuration file, settings are organised into <i>groups</i>, for
 	  example, there is a "general" group of
 	  standard settings, and there is an "alsa" group with settings that pertain to the ALSA
 	  back end. Here is an example of a typical configuration file:</p>
@@ -223,7 +223,7 @@
 
     <option>
     <p><opt>udp_port_range=</opt><arg>range</arg><opt>;</opt></p>
-    <optdesc><p>Use this in conjunction with the prevous setting to specify the 
+    <optdesc><p>Use this in conjunction with the previous setting to specify the
     <arg>range</arg> of ports that can be checked for availability. Only three ports are 
     needed.
     The default is 100, thus 100 ports will be checked from port 6001 upwards until three 
@@ -364,7 +364,7 @@
     <option>
     <p><opt>interface=</opt><arg>"name"</arg><opt>;</opt></p>
     <optdesc><p>Use this advanced setting if you want to confine Shairport Sync to the 
-    named interface. Leave it commented out to get the default bahaviour.</p></optdesc>
+    named interface. Leave it commented out to get the default behaviour.</p></optdesc>
     </option>
     
     <option>
@@ -583,7 +583,7 @@
     specify.</p><p>"S" means signed; "U" means unsigned; BE means big-endian and LE means 
     little-endian. Except where stated (using *LE or *BE), endianness matches that of the 
     processor. The default is "S16".</p><p>If you are using a hardware mixer, the best 
-    setting is S16, as audio will pass through Shairport Sync unmodifed except for 
+    setting is S16, as audio will pass through Shairport Sync unmodified except for
     interpolation. If you are using the software mixer, use 32- or 24-bit, if your device 
     is capable of it, to get the lowest possible levels of dither.
     </p></optdesc>
diff --git a/metadata_hub.h b/metadata_hub.h
index 784f6621f..47965d5d8 100644
--- a/metadata_hub.h
+++ b/metadata_hub.h
@@ -106,7 +106,7 @@ void metadata_hub_release_track_artwork(void);
 // these functions lock and unlock the read-write mutex on the metadata hub and run the watchers
 // afterwards
 void metadata_hub_modify_prolog(void);
-void metadata_hub_modify_epilog(int modified); // set to true if modifications occured, 0 otherwise
+void metadata_hub_modify_epilog(int modified); // set to true if modifications occurred, 0 otherwise
 
 // these are for safe reading
 void metadata_hub_read_prolog(void);
diff --git a/player.c b/player.c
index 179828138..0b0ec65b6 100644
--- a/player.c
+++ b/player.c
@@ -170,7 +170,7 @@ static inline seq_t SUCCESSOR(seq_t x) {
 
 // used in seq_diff and seq_order
 
-// anything with ORDINATE in it must be proctected by the ab_mutex
+// anything with ORDINATE in it must be protected by the ab_mutex
 static inline int32_t ORDINATE(seq_t x, seq_t base) {
   int32_t p = x;    // int32_t from seq_t, i.e. uint16_t, so okay
   int32_t q = base; // int32_t from seq_t, i.e. uint16_t, so okay
@@ -1921,7 +1921,7 @@ void *player_thread_func(void *arg) {
   while (1) {
     pthread_testcancel();                     // allow a pthread_cancel request to take effect.
     abuf_t *inframe = buffer_get_frame(conn); // this has cancellation point(s), but it's not
-                                              // guaranteed that they'll aways be executed
+                                              // guaranteed that they'll always be executed
     if (inframe) {
       inbuf = inframe->data;
       inbuflength = inframe->length;
@@ -1942,7 +1942,7 @@ void *player_thread_func(void *arg) {
             debug(1, "Failed to allocate memory for a silent frame silence buffer.");
           } else {
             // the player may change the contents of the buffer, so it has to be zeroed each time;
-            // might as well malloc and freee it locally
+            // might as well malloc and free it locally
             conn->previous_random_number = generate_zero_frames(
                 silence, conn->max_frames_per_packet * conn->output_sample_ratio,
                 config.output_format, conn->enable_dither, conn->previous_random_number);
@@ -1964,7 +1964,7 @@ void *player_thread_func(void *arg) {
             debug(1, "Failed to allocate memory for a flush silence buffer.");
           } else {
             // the player may change the contents of the buffer, so it has to be zeroed each time;
-            // might as well malloc and freee it locally
+            // might as well malloc and free it locally
             conn->previous_random_number = generate_zero_frames(
                 silence, conn->max_frames_per_packet * conn->output_sample_ratio,
                 config.output_format, conn->enable_dither, conn->previous_random_number);
diff --git a/player.h b/player.h
index cb197e4a8..724d5a789 100644
--- a/player.h
+++ b/player.h
@@ -55,7 +55,7 @@ typedef struct audio_buffer_entry { // decoded audio packets
 // Resend requests will be spaced out evenly in the latency period, subject to a minimum interval of
 // about 0.25 seconds.
 // Each buffer occupies 352*4 bytes plus about, say, 64 bytes of overhead in various places, say
-// rougly 1,500 bytes per buffer.
+// roughly 1,500 bytes per buffer.
 // Thus, 2048 buffers will occupy about 3 megabytes -- no big deal in a normal machine but maybe a
 // problem in an embedded device.
 
diff --git a/rtsp.c b/rtsp.c
index 4a72250af..a802ba96f 100644
--- a/rtsp.c
+++ b/rtsp.c
@@ -1137,7 +1137,7 @@ void handle_set_parameter_parameter(rtsp_conn_info *conn, rtsp_message *req,
 //    Specifically, it's the "X-Apple-Client-Name" string
 //    'snua' -- A "user agent" -- e.g. "iTunes/12..." -- has opened a play
 //    session. Specifically, it's the "User-Agent" string
-//    The next two two tokens are to facilitiate remote control of the source.
+//    The next two two tokens are to facilitate remote control of the source.
 //    There is some information at http://nto.github.io/AirPlay.html about
 //    remote control of the source.
 //
@@ -1869,7 +1869,7 @@ static void handle_announce(rtsp_conn_info *conn, rtsp_message *req, rtsp_messag
       unsigned int i;
       for (i = 0; i < sizeof(conn->stream.fmtp) / sizeof(conn->stream.fmtp[0]); i++)
         conn->stream.fmtp[i] = atoi(strsep(&pfmtp, " \t"));
-      // here we should check the sanity ot the fmtp values
+      // here we should check the sanity of the fmtp values
       // for (i = 0; i < sizeof(conn->stream.fmtp) / sizeof(conn->stream.fmtp[0]); i++)
       //  debug(1,"  fmtp[%2d] is: %10d",i,conn->stream.fmtp[i]);
 
diff --git a/scripts/shairport-sync.in b/scripts/shairport-sync.in
index f229f19bb..017de0791 100755
--- a/scripts/shairport-sync.in
+++ b/scripts/shairport-sync.in
@@ -47,7 +47,7 @@ do_start()
 {
 	# Return
 	#   0 if daemon has been started
-	#   1 if PID directory didn't exist and couldn't be created with approproate permission
+	#   1 if PID directory didn't exist and couldn't be created with appropriate permission
 	#   2 if daemon was already running
 	#   3 if daemon could not be started
         [ -e /var/run/shairport-sync ] || ( mkdir -p /var/run/shairport-sync && chown shairport-sync:shairport-sync /var/run/shairport-sync ) || return 1
diff --git a/shairport-sync.spec b/shairport-sync.spec
index 53daf65e9..bcc3b5b70 100644
--- a/shairport-sync.spec
+++ b/shairport-sync.spec
@@ -79,12 +79,12 @@ getent passwd %{name} &> /dev/null || useradd --system -c "%{name} User" \
 * Thu Dec 21 2017 Mike Brady <mikebrady@eircom.net> 3.1.7
 - Bug fix for unexpectedly resuming play at full volume from iOS 11.2 and macOS 10.3.2.
 * Mon Dec 11 2017 Mike Brady <mikebrady@eircom.net> 3.1.5
-- Bug fixes and better compatability with iOS 11.2 and mac OS 10.13.2.
+- Bug fixes and better compatibility with iOS 11.2 and mac OS 10.13.2.
 - Better AirPlay synchronisation.
 * Wed Sep 13 2017 Bill Peck <bpeck@redhat.com> 3.1.2-1
 - New upstream release
 - The default value for the alsa setting mute_using_playback_switch has
-  been changed to "no" for compatability with other audio players on the
+  been changed to "no" for compatibility with other audio players on the
   same machine. Because of this you may need to unmute your audio device
   if you are upgrading from an older release.
 - Fixed bugs that made Shairport Sync drop out or become unavailable when
diff --git a/shairport.c b/shairport.c
index 6d74cae4b..21d20dfd4 100644
--- a/shairport.c
+++ b/shairport.c
@@ -1143,7 +1143,7 @@ int parse_options(int argc, char **argv) {
   /* Check if we are called with -d or --daemon or -j or justDaemoniseNoPIDFile options*/
   if ((daemonisewith != 0) || (daemonisewithout != 0)) {
     fprintf(stderr, "%s was built without libdaemon, so does not support daemonisation using the "
-                    "-d, --deamon, -j or --justDaemoniseNoPIDFile options\n",
+                    "-d, --daemon, -j or --justDaemoniseNoPIDFile options\n",
             config.appName);
     exit(EXIT_FAILURE);
   }
@@ -1494,7 +1494,7 @@ int main(int argc, char **argv) {
     return 1;
   }
 
-  /* Set indentification string for the daemon for both syslog and PID file */
+  /* Set identification string for the daemon for both syslog and PID file */
   daemon_pid_file_ident = daemon_log_ident = daemon_ident_from_argv0(argv[0]);
 
   daemon_pid_file_proc = pid_file_proc;
@@ -1696,7 +1696,7 @@ int main(int argc, char **argv) {
   debug(1, "statistics_requester status is %d.", config.statistics_requested);
 #if CONFIG_LIBDAEMON
   debug(1, "daemon status is %d.", config.daemonise);
-  debug(1, "deamon pid file path is \"%s\".", pid_file_proc());
+  debug(1, "daemon pid file path is \"%s\".", pid_file_proc());
 #endif
   debug(1, "rtsp listening port is %d.", config.port);
   debug(1, "udp base port is %d.", config.udp_port_base);
diff --git a/tinyhttp/chunk.h b/tinyhttp/chunk.h
index 9736e8364..e0df06002 100644
--- a/tinyhttp/chunk.h
+++ b/tinyhttp/chunk.h
@@ -33,7 +33,7 @@ extern "C" {
 
 /**
  * Parses the size out of a chunk-encoded HTTP response. Returns non-zero if it
- * needs more data. Retuns zero success or error. When error: size == -1 On
+ * needs more data. Returns zero success or error. When error: size == -1 On
  * success, size = size of following chunk data excluding trailing \r\n. User is
  * expected to process or otherwise seek past chunk data up to the trailing
  * \r\n. The state parameter is used for internal state and should be
diff --git a/tinysvcmdns.c b/tinysvcmdns.c
index bb89e50fd..4cb6fb4c4 100644
--- a/tinysvcmdns.c
+++ b/tinysvcmdns.c
@@ -1576,7 +1576,7 @@ void mdnsd_set_hostname(struct mdnsd *svr, const char *hostname, uint32_t ip) {
   struct rr_entry *a_e = NULL, *nsec_e = NULL;
 
   // currently can't be called twice
-  // dont ask me what happens if the IP changes
+  // don't ask me what happens if the IP changes
   assert(svr->hostname == NULL);
 
   a_e = rr_create_a(create_nlabel(hostname), ip); // 120 seconds automatically
@@ -1596,7 +1596,7 @@ void mdnsd_set_hostname_v6(struct mdnsd *svr, const char *hostname, struct in6_a
   struct rr_entry *aaaa_e = NULL, *nsec_e = NULL;
 
   // currently can't be called twice
-  // dont ask me what happens if the IP changes
+  // don't ask me what happens if the IP changes
   assert(svr->hostname == NULL);
 
   aaaa_e = rr_create_aaaa(create_nlabel(hostname), addr); // 120 seconds automatically