]> git.ipfire.org Git - thirdparty/shairport-sync.git/commitdiff
Update shairport-sync.7.xml
authorMike Brady <mikebrady@eircom.net>
Fri, 10 Jun 2016 11:27:15 +0000 (12:27 +0100)
committerGitHub <noreply@github.com>
Fri, 10 Jun 2016 11:27:15 +0000 (12:27 +0100)
Fix a few typos.

man/shairport-sync.7.xml

index 0ba76f5671554e8bcf6d1db6dd31011f16d502f5..530f11146054e7221944038c984f958abefd7d12 100644 (file)
@@ -65,7 +65,7 @@
 
   <description>
     <p>shairport-sync  plays  audio  streamed  from  iTunes or from an AirPlay
-    device to an ALSA-compatible audio output device.</p>
+    device to an Advanced Linux Sound Architecture (ALSA)-compatible audio output device.</p>
 
     <p> A feature of shairport-sync is that the audio is played synchronously.
     This means that if many devices are playing the same stream at the same
@@ -74,7 +74,7 @@
     enabling, for example, simultaneous multi-room operation.
     </p>
     
-    <p>shairport-sync can additionally be compiled and configured to stream raw audio to a pipe or to stdout.</p>
+    <p>shairport-sync can be compiled to stream raw audio to a pipe or to stdout. It can also be compiled to stream metadata to a pipe or socket.</p>
     
     <p>Settings can be made using the configuration file (recommended for all new installations) or by using command-line options.</p>
  
     This might be because the sound becomes inaudible at the lowest setting and unbearably loud at the highest setting --
     indeed, many domestic HiFi systems have a volume control range of just 60 to 80dB.</p>
     <p>Another potential use might be where the range specified by the mixer does not match the capabilities of the device.
-    For example, the Raspberry Pi's DAC that feeds the built-in audio jack claims a range of 106 dB but has a useful range of only about 35dB.
+    For example, the Raspberry Pi's DAC that feeds the built-in audio jack claims a range of 106 dB but has a useful range of only about 3dB.
     The setting allows you to specify the maximum range from highest to lowest.
-    The range suggested for the Raspberry Pi's built-in audio DAC, which feeds the headphone jack, is 35.
+    The range suggested for the Raspberry Pi's built-in audio DAC, which feeds the headphone jack, is 30.
     Using it in this case gives the volume control a much more useful range of settings.</p>
     <p>As a third example, you can actually extend the range provided by a mixer.
     Many cheaper DACs have hardware mixers that offer a restricted attenuation range.
     <option>
     <p><opt>disable_synchronization=</opt><arg>"no"</arg><opt>;</opt></p>
     <optdesc>This is an advanced setting and is for debugging only. Set to "yes" to disable synchronization. Default is "no".
-    If you use it to disable synchronisation, then soner or later you'll experience audio glitches due to
+    If you use it to disable synchronisation, then sooner or later you'll experience audio glitches due to
     audio buffer overflow or underflow.
     </optdesc>
     </option>
     
     <option><p><opt>"PIPE" SETTINGS</opt></p></option>
     <p>These settings are for the PIPE backend, used to route audio to a named unix pipe. The audio is in raw CD audio format: PCM 16 bit little endian, 44,100 samples per second,
-    stereo.</p>
+    interleaved stereo.</p>
     <p>Use the <arg>name</arg> setting to set the name and location of the pipe.</p>
     <p>There are two further settings affecting timing that might be useful if the pipe reader is, for example,
-    a program to play an audio stream such as <opt>aplay</opt>. The <arg>audio_backend_latency_offset</arg> affects precisely when the first audio packet is sent
+    a program to play an audio stream such as <opt>aplay</opt>. The <arg>audio_backend_latency_offset</arg> affects precisely
+    when the first audio packet is sent
     and the <arg>audio_backend_buffer_desired_length</arg> setting affects the nominal output buffer size.</p>
     <p>These are the settings available within the <opt>pipe</opt> group:</p>
 
     <option>
     <p><opt>name=</opt><arg>"/path/to/pipe"</arg><opt>;</opt></p>
-    <optdesc>Use this to specify the name and location of the pipe. The pipe will be created and opened when shairport-sync starts up and will be closed upon shutdown.
+    <optdesc>Use this to specify the name and location of the pipe. The pipe will be created and opened when shairport-sync starts up
+    and will be closed upon shutdown.
     Frames of audio will be sent to the pipe in packets of 352 frames and will be discarded if the pipe has not have a reader attached.
     The sender will wait for up to five seconds for a packet to be written before discarding it.</optdesc>
     </option>
     <p><opt>audio_backend_buffer_desired_length=</opt><arg>buffer_length_in_frames</arg><opt>;</opt></p>
     <optdesc>    
     Use this setting, in frames, to set the size of the output buffer. It works by determining how soon the second and subsequent packets of
-    audio frames are sent to to the libao system.
+    audio frames are sent to the libao system.
     For example, if you send the first packet of audio exactly when it is due and, using a <arg>audio_backend_buffer_desired_length</arg> setting of 44100,
     send subsequent packets of audio a second before they are due to be played, they will be buffered in the stdout reader's buffer, giving it a nominal buffer size of 44,100 frames.
     Note that if the libao system consumes audio packets faster or slower than they are supplied, the buffer will eventually empty or overflow --
     <p>shairport-sync can process metadata provided by the source, such as Track Number, Album Name, cover art, etc. and can provide additional metadata such as volume level,
     pause/resume, etc. It sends the metadata to a pipe, by default <file>/tmp/shairport-sync-metadata</file>.
     To process metadata, shairport-sync must have been compiled with metadata support included.
-    You can check that this is so by running <opt>shairport-sync -V</opt>; the identification string will contain the word <opt>metadata</opt>.</p>
+    You can check that this is so by running the command <opt>$ shairport-sync -V</opt>; the identification string will contain the word <opt>metadata</opt>.</p>
     <p>Please note that different sources provide different levels of metadata. Some provide a lot; some provide almost none.</p>
     <p>The <opt>metadata</opt> group of settings allow you to enable metadata handling and to control certain aspects of it:</p>
 
     </option>
     <option>
     <p><opt>pipe_name=</opt><arg>"filepathname"</arg><opt>;</opt></p>
-    <optdesc>Specify the absolute path name of the pipe through which metadata should be sent The default is <file>/tmp/shairport-sync-metadata</file>".</optdesc>
+    <optdesc>Specify the absolute path name of the pipe through which metadata should be sent The default is <file>/tmp/shairport-sync-metadata</file>.</optdesc>
     </option>
     
     <option>
     <p><opt>socket_address=</opt><arg>"hostnameOrIP"</arg><opt>;</opt></p>
     <optdesc>If <arg>hostnameOrIP</arg> is set to a host name or and IP address, UDP packets containing metadata will be sent to this address.
-    May be a multicast address. "socket-port" must be non-zero and "enabled" must be set to "yes".</optdesc>
+    May be a multicast address. Additionally, <arg>socket-port</arg> must be non-zero and <arg>enabled</arg> must be set to "yes".</optdesc>
     </option>
     <option>
     <p><opt>socket_port=</opt><arg>port</arg><opt>;</opt></p>