Here you can specify a program and its arguments that will be run just after a play session ends. Be careful to include the full path to the application. The application must be marked as executable and, if it is a script, its first line must begin with the standard \fI#!/bin/...\f1 as appropriate.
.TP
\fBwait_for_completion=\f1\fI"choice"\f1\fB;\f1
-Set \fIchoice\f1 to "yes" to make Shairport Sync wait until the programs specified in the \fBrun_this_before_play_begins\f1 and \fBrun_this_after_play_ends=\f1 have completed execution before continuing. The default is "no".
+Set \fIchoice\f1 to "yes" to make Shairport Sync wait until the programs specified in the \fBrun_this_before_play_begins\f1 and \fBrun_this_after_play_ends\f1 have completed execution before continuing. The default is "no".
.TP
-\fBallow_session_interruption=\f1\fI"no"\f1\fB;\f1
-Comment Here
+\fBallow_session_interruption=\f1\fI"choice"\f1\fB;\f1
+If \fBchoice\f1 is set to "yes", then another source will be able to interrupt an existing play session and start a new one. When set to "no" (the default), other devices attempting to interrupt a session will fail, receiving a busy signal.
.TP
-\fBsession_timeout=\f1\fI120\f1\fB;\f1
-Comment Here
+\fBsession_timeout=\f1\fIseconds\f1\fB;\f1
+If a play session has been established and the source disappears without warning (such as a device going out of range of a network) then wait for \fIseconds\f1 seconds before ending the session. Once the session has terminated, other devices can use it. The default is 120 seconds.
.TP
\fB"ALSA" SETTINGS\f1
-These are the settings available within the \fBalsa\f1 group:
+These settings are for the ALSA back end, used used to communicate with audio output devices in the ALSA system. (By the way, you can use tools such as \fBalsamixer\f1 or \fBaplay\f1 to discover what devices are available.) Use these settings to select the output device and the mixer control to be used to control the output volume. You can additionally set the desired size of the output buffer and you can adjust overall latency. Here are the \fBalsa\f1 group settings:
.TP
-\fBoutput_device=\f1\fI"default"\f1\fB;\f1
-Comment Here
+\fBoutput_device=\f1\fI"output_device"\f1\fB;\f1
+Use the output device called \fIoutput_device\f1. The default is the device called "device".
.TP
-\fBmixer_type=\f1\fI"software"\f1\fB;\f1
-"software" or "hardware"
.TP
-\fBmixer_device=\f1\fI"default"\f1\fB;\f1
-actually, the mixer default is whatever the output_device is. Normally you wouldn't have to use this.
+\fBmixer_control_name=\f1\fI"name"\f1\fB;\f1
+Specify the \fIname\f1 of the mixer control to be used by shairport-sync to control the volume. The mixer control must be on the mixer device, which by default is the output device. If you do not specify a mixer control name, shaiport-sync will control the volume in software. \fBmixer_type=\f1\fI"mixer_type"\f1\fB;\f1
+This setting is deprecated and will be removed soon. If you wish to use a mixer control to control the volume, then set \fImixer_type\f1 to "hardware". The default is "software".
.TP
-\fBmixer_control_name=\f1\fI"PCM"\f1\fB;\f1
-the name of the mixer to use -- there is no default.
+\fBmixer_device=\f1\fI"mixer_device"\f1\fB;\f1
+By default, the mixer is assumed to be output_device is. Use this setting to specify a device other than the output device.
.TP
-\fBaudio_backend_latency_offset=\f1\fI0\f1\fB;\f1
-Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+\fBaudio_backend_latency_offset=\f1\fIoffset\f1\fB;\f1
+Set this \fIoffset\f1, in frames, to compensate for a fixed delay in the audio back end. For example, if the output device delays by 100 ms, set this to -4410.
.TP
-\fBaudio_backend_buffer_desired_length=\f1\fI6615\f1\fB;\f1
-If set too small, buffer underflow occurs on low-powered machines. Too long and the response times with software mixer become annoying.
+\fBaudio_backend_buffer_desired_length=\f1\fIlength\f1\fB;\f1
+Use this to set the desired number frames to be in the output device's hardware output buffer. The default is 6,615 frames, or 0.15 seconds. If set too small, buffer underflow may occur on low-powered machines. If too large, the response times when using a software mixer become annoying, or it may exceed the hardware buffer size. It may need to be larger on low-powered machines performing other tasks, such as processing metadata.
.TP
\fB"PIPE" SETTINGS\f1
-These are the settings available within the \fBpipe\f1 group:
+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.
+
+Use the \fIname\f1 setting to set the name and location of the pipe.
+
+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 \fBaplay\f1. The \fIaudio_backend_latency_offset\f1 affects precisely when the first audio packet is sent and the \fIaudio_backend_buffer_desired_length\f1 setting affects the nominal output buffer size.
+
+These are the settings available within the \fBpipe\f1 group:
.TP
-\fBaudio_backend_latency_offset=\f1\fI0\f1\fB;\f1
-Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+\fBname=\f1\fI"/path/to/pipe"\f1\fB;\f1
+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.
.TP
-\fBaudio_backend_buffer_desired_length=\f1\fI44100\f1\fB;\f1
-Comment Here
+\fBaudio_backend_latency_offset=\f1\fIoffset_in_frames\f1\fB;\f1
+Packets of audio frames are written to the pipe synchronously -- that is, they are written to at exactly the time they should be played. You can offset the time of initial audio output relative to its nominal time using this setting. For example to send an audio stream to the pipe 100 milliseconds before it is due to be played, set this to -4410.
.TP
-\fBname=\f1\fI"/path/to/pipe"\f1\fB;\f1
-there is no default pipe name for the output
+\fBaudio_backend_buffer_desired_length=\f1\fIbuffer_length_in_frames\f1\fB;\f1
+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 the pipe. For example, if you send the first packet of audio exactly when it is due and, using a \fIaudio_backend_buffer_desired_length\f1 setting of 44100, send subsequent packets of audio a second before they are due to be played, they will be buffered in the pipe reader's buffer, giving it a nominal buffer size of 44,100 frames. Note that if the pipe reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually -- Shairport Sync performs no stuffing or interpolation when writing to a pipe.
.TP
\fB"STDOUT" SETTINGS\f1
-These are the settings available within the \fBstdout\f1 group:
+These settings are for the STDOUT backend, used to route audio to standard output ("stdout"). The audio is in raw CD audio format: PCM 16 bit little endian, 44,100 samples per second, stereo.
+
+There are two settings affecting timing that might be useful if the stdout reader is, for example, a program to play an audio stream such as \fBaplay\f1. The \fIaudio_backend_latency_offset\f1 affects precisely when the first audio packet is sent and the \fIaudio_backend_buffer_desired_length\f1 setting affects the nominal output buffer size.
+
+These are the settings available within the \fBstdout\f1 group:
.TP
-\fBaudio_backend_latency_offset=\f1\fI0\f1\fB;\f1
-Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+\fBaudio_backend_latency_offset=\f1\fIoffset_in_frames\f1\fB;\f1
+Packets of audio frames are written to stdout synchronously -- that is, they are written at exactly the time they should be played. You can offset the time of initial audio output relative to its nominal time using this setting. For example to send an audio stream to stdout 100 milliseconds before it is due to be played, set this to -4410.
.TP
-\fBaudio_backend_buffer_desired_length=\f1\fI44100\f1\fB;\f1
-Comment Here
+\fBaudio_backend_buffer_desired_length=\f1\fIbuffer_length_in_frames\f1\fB;\f1
+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 stdout. For example, if you send the first packet of audio exactly when it is due and, using a \fIaudio_backend_buffer_desired_length\f1 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 stdout reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually -- Shairport Sync performs no stuffing or interpolation when writing to stdout.
.SH OPTIONS
Many of the options take sensible default values, so you can normally ignore most of them. See the EXAMPLES section for typical usages.
</option>
<option><p><opt>"METADATA" SETTINGS</opt></p></option>
- <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 provides 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 tht this is so by running <opt>shairport-sync -V</opt>; the identification string will contain the word <opt>metadata</opt>.</p><p>The <opt>metadata</opt> group of settings allow you to enable metadata handling and to control certain aspects of it:</p>
+ <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 provides 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 tht this is so by running <opt>shairport-sync -V</opt>; the identification string will contain the word <opt>metadata</opt>.</p>
+ <p>The <opt>metadata</opt> group of settings allow you to enable metadata handling and to control certain aspects of it:</p>
<option>
<p><opt>enabled=</opt><arg>"choice"</arg><opt>;</opt></p>
- <optdesc>Set the <arg>choice</arg> to "yes" to enable Shairport Sync to look for metadata from the audio source and to forward it, along with metadata generated by Shairport Sync itself, to the metadata pipe. The default is "no".</optdesc>
+ <optdesc>Set the <arg>choice</arg> to "yes" to enable Shairport Sync to look for metadata from the audio source and to forward it,
+ along with metadata generated by Shairport Sync itself, to the metadata pipe. The default is "no".</optdesc>
</option>
<option>
<p><opt>include_cover_art=</opt><arg>"choice"</arg><opt>;</opt></p>
- <optdesc>Set the <arg>choice</arg> to "yes" to enable Shairport Sync to look for cover art from the audio source and to forward it to the metadata pipe. A reason for not enabling cover art is that the images can sometimes be very large and mey delay transmission of subsequent metadata through the pipe. The default is "no".</optdesc>
+ <optdesc>Set the <arg>choice</arg> to "yes" to enable Shairport Sync to look for cover art from the audio source and to forward it to the metadata pipe.
+ A reason for not enabling cover art is that the images can sometimes be very large and mey delay transmission of subsequent metadata through the pipe.
+ The default is "no".</optdesc>
</option>
<option>
<p><opt>pipe_name=</opt><arg>"filepathname"</arg><opt>;</opt></p>
</option>
<option><p><opt>"SESSIONCONTROL" SETTINGS</opt></p></option>
- <p>Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes. You specify them using the sessioncontrol group settings run_this_before_play_begins and run_this_after_play_ends. </p>
+ <p>Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes.
+ You specify them using the sessioncontrol group settings run_this_before_play_begins and run_this_after_play_ends. </p>
<option>
</option>
<option>
<p><opt>wait_for_completion=</opt><arg>"choice"</arg><opt>;</opt></p>
- <optdesc>Set <arg>choice</arg> to "yes" to make Shairport Sync wait until the programs specified in the <opt>run_this_before_play_begins</opt> and <opt>run_this_after_play_ends</opt> have completed execution before continuing. The default is "no".</optdesc>
+ <optdesc>Set <arg>choice</arg> to "yes" to make Shairport Sync wait until the programs specified in the <opt>run_this_before_play_begins</opt>
+ and <opt>run_this_after_play_ends</opt> have completed execution before continuing. The default is "no".</optdesc>
</option>
<option>
- <p><opt>allow_session_interruption=</opt><arg>"no"</arg><opt>;</opt></p>
- <optdesc>Comment Here</optdesc>
+ <p><opt>allow_session_interruption=</opt><arg>"choice"</arg><opt>;</opt></p>
+ <optdesc>If <opt>choice</opt> is set to "yes", then another source will be able to interrupt an existing play session and start a new one.
+ When set to "no" (the default), other devices attempting to interrupt a session will fail, receiving a busy signal.</optdesc>
</option>
<option>
- <p><opt>session_timeout=</opt><arg>120</arg><opt>;</opt></p>
- <optdesc>Comment Here</optdesc>
+ <p><opt>session_timeout=</opt><arg>seconds</arg><opt>;</opt></p>
+ <optdesc>If a play session has been established and the source disappears without warning (such as a device going out of range of a network)
+ then wait for <arg>seconds</arg> seconds before ending the session. Once the session has terminated, other devices can use it.
+ The default is 120 seconds.</optdesc>
</option>
<option><p><opt>"ALSA" SETTINGS</opt></p></option>
- These are the settings available within the <opt>alsa</opt> group:
+ <p>These settings are for the ALSA back end, used used to communicate with audio output devices in the ALSA system.
+ (By the way, you can use tools such as <opt>alsamixer</opt> or <opt>aplay</opt> to discover what devices are available.)
+ Use these settings to select the output device and the mixer control to be used to control the output volume.
+ You can additionally set the desired size of the output buffer and you can adjust overall latency. Here are the <opt>alsa</opt> group settings:</p>
<option>
- <p><opt>output_device=</opt><arg>"default"</arg><opt>;</opt></p>
- <optdesc>Comment Here</optdesc>
+ <p><opt>output_device=</opt><arg>"output_device"</arg><opt>;</opt></p>
+ <optdesc>Use the output device called <arg>output_device</arg>. The default is the device called "device".</optdesc>
</option>
<option>
- <p><opt>mixer_type=</opt><arg>"software"</arg><opt>;</opt></p>
- <optdesc>"software" or "hardware"</optdesc>
- </option>
<option>
- <p><opt>mixer_device=</opt><arg>"default"</arg><opt>;</opt></p>
- <optdesc>actually, the mixer default is whatever the output_device is. Normally you wouldn't have to use this.</optdesc>
+ <p><opt>mixer_control_name=</opt><arg>"name"</arg><opt>;</opt></p>
+ <optdesc>Specify the <arg>name</arg> of the mixer control to be used by shairport-sync to control the volume.
+ The mixer control must be on the mixer device, which by default is the output device.
+ If you do not specify a mixer control name, shaiport-sync will control the volume in software.</optdesc>
+ </option>
+ <p><opt>mixer_type=</opt><arg>"mixer_type"</arg><opt>;</opt></p>
+ <optdesc>This setting is deprecated and will be removed soon. If you wish to use a mixer control to control the volume, then set <arg>mixer_type</arg> to "hardware".
+ The default is "software".</optdesc>
</option>
<option>
- <p><opt>mixer_control_name=</opt><arg>"PCM"</arg><opt>;</opt></p>
- <optdesc>the name of the mixer to use -- there is no default.</optdesc>
+ <p><opt>mixer_device=</opt><arg>"mixer_device"</arg><opt>;</opt></p>
+ <optdesc>By default, the mixer is assumed to be output_device is. Use this setting to specify a device other than the output device.</optdesc>
</option>
<option>
- <p><opt>audio_backend_latency_offset=</opt><arg>0</arg><opt>;</opt></p>
- <optdesc>Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.</optdesc>
+ <p><opt>audio_backend_latency_offset=</opt><arg>offset</arg><opt>;</opt></p>
+ <optdesc>Set this <arg>offset</arg>, in frames, to compensate for a fixed delay in the audio back end.
+ For example, if the output device delays by 100 ms, set this to -4410.</optdesc>
</option>
<option>
- <p><opt>audio_backend_buffer_desired_length=</opt><arg>6615</arg><opt>;</opt></p>
- <optdesc>If set too small, buffer underflow occurs on low-powered machines. Too long and the response times with software mixer become annoying.</optdesc>
+ <p><opt>audio_backend_buffer_desired_length=</opt><arg>length</arg><opt>;</opt></p>
+ <optdesc>Use this to set the desired number frames to be in the output device's hardware output buffer.
+ The default is 6,615 frames, or 0.15 seconds. If set too small, buffer underflow may occur on low-powered machines.
+ If too large, the response times when using a software mixer become annoying, or it may exceed the hardware buffer size.
+ It may need to be larger on low-powered machines performing other tasks, such as processing metadata.</optdesc>
</option>
<option><p><opt>"PIPE" SETTINGS</opt></p></option>
- These are the settings available within the <opt>pipe</opt> group:
+ <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>
+ <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
+ 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>audio_backend_latency_offset=</opt><arg>0</arg><opt>;</opt></p>
- <optdesc>Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.</optdesc>
+ <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.
+ 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>
+
<option>
- <p><opt>audio_backend_buffer_desired_length=</opt><arg>44100</arg><opt>;</opt></p>
- <optdesc>Comment Here</optdesc>
+ <p><opt>audio_backend_latency_offset=</opt><arg>offset_in_frames</arg><opt>;</opt></p>
+ <optdesc>
+ Packets of audio frames are written to the pipe synchronously -- that is, they are written to at exactly the time they should be played.
+ You can offset the time of initial audio output relative to its nominal time using this setting.
+ For example to send an audio stream to the pipe 100 milliseconds before it is due to be played, set this to -4410.</optdesc>
</option>
+
<option>
- <p><opt>name=</opt><arg>"/path/to/pipe"</arg><opt>;</opt></p>
- <optdesc>there is no default pipe name for the output</optdesc>
+ <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 the pipe.
+ 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 pipe reader's buffer, giving it a nominal buffer size of 44,100 frames.
+ Note that if the pipe reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually --
+ Shairport Sync performs no stuffing or interpolation when writing to a pipe.
+ </optdesc>
</option>
<option><p><opt>"STDOUT" SETTINGS</opt></p></option>
- These are the settings available within the <opt>stdout</opt> group:
+ <p>These settings are for the STDOUT backend, used to route audio to standard output ("stdout").
+ The audio is in raw CD audio format: PCM 16 bit little endian, 44,100 samples per second, stereo.</p>
+ <p>There are two settings affecting timing that might be useful if the stdout 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
+ 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>stdout</opt> group:</p>
<option>
- <p><opt>audio_backend_latency_offset=</opt><arg>0</arg><opt>;</opt></p>
- <optdesc>Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.</optdesc>
+ <p><opt>audio_backend_latency_offset=</opt><arg>offset_in_frames</arg><opt>;</opt></p>
+ <optdesc>
+ Packets of audio frames are written to stdout synchronously -- that is, they are written at exactly the time they should be played.
+ You can offset the time of initial audio output relative to its nominal time using this setting.
+ For example to send an audio stream to stdout 100 milliseconds before it is due to be played, set this to -4410.</optdesc>
</option>
+
<option>
- <p><opt>audio_backend_buffer_desired_length=</opt><arg>44100</arg><opt>;</opt></p>
- <optdesc>Comment Here</optdesc>
+ <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 stdout.
+ 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 stdout reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually --
+ Shairport Sync performs no stuffing or interpolation when writing to stdout.
+ </optdesc>
</option>
+
</section>
<options>
<p><b>"METADATA" SETTINGS</b></p>
- <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 provides the metadata to a pipe, by default <em>/tmp/shairport-sync-metadata</em>. To process metadata, Shairport Sync must have been compiled with metadata support included. You can check tht this is so by running <b>shairport-sync -V</b>; the identification string will contain the word <b>metadata</b>.</p><p>The <b>metadata</b> group of settings allow you to enable metadata handling and to control certain aspects of it:</p>
+ <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 provides the metadata to a pipe, by default <em>/tmp/shairport-sync-metadata</em>.
+ To process metadata, Shairport Sync must have been compiled with metadata support included.
+ You can check tht this is so by running <b>shairport-sync -V</b>; the identification string will contain the word <b>metadata</b>.</p>
+ <p>The <b>metadata</b> group of settings allow you to enable metadata handling and to control certain aspects of it:</p>
<p><b>enabled=</b><em>"choice"</em><b>;</b></p>
- Set the <em>choice</em> to "yes" to enable Shairport Sync to look for metadata from the audio source and to forward it, along with metadata generated by Shairport Sync itself, to the metadata pipe. The default is "no".
+ Set the <em>choice</em> to "yes" to enable Shairport Sync to look for metadata from the audio source and to forward it,
+ along with metadata generated by Shairport Sync itself, to the metadata pipe. The default is "no".
<p><b>include_cover_art=</b><em>"choice"</em><b>;</b></p>
- Set the <em>choice</em> to "yes" to enable Shairport Sync to look for cover art from the audio source and to forward it to the metadata pipe. A reason for not enabling cover art is that the images can sometimes be very large and mey delay transmission of subsequent metadata through the pipe. The default is "no".
+ Set the <em>choice</em> to "yes" to enable Shairport Sync to look for cover art from the audio source and to forward it to the metadata pipe.
+ A reason for not enabling cover art is that the images can sometimes be very large and mey delay transmission of subsequent metadata through the pipe.
+ The default is "no".
<p><b>pipe_name=</b><em>"filepathname"</em><b>;</b></p>
<p><b>"SESSIONCONTROL" SETTINGS</b></p>
- <p>Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes. You specify them using the sessioncontrol group settings run_this_before_play_begins and run_this_after_play_ends. </p>
+ <p>Shairport Sync can run programs just before it starts to play an audio stream and just after it finishes.
+ You specify them using the sessioncontrol group settings run_this_before_play_begins and run_this_after_play_ends. </p>
<p><b>wait_for_completion=</b><em>"choice"</em><b>;</b></p>
- Set <em>choice</em> to "yes" to make Shairport Sync wait until the programs specified in the <b>run_this_before_play_begins</b> and <b>run_this_after_play_ends=</b> have completed execution before continuing. The default is "no".
+ Set <em>choice</em> to "yes" to make Shairport Sync wait until the programs specified in the <b>run_this_before_play_begins</b>
+ and <b>run_this_after_play_ends</b> have completed execution before continuing. The default is "no".
- <p><b>allow_session_interruption=</b><em>"no"</em><b>;</b></p>
- Comment Here
+ <p><b>allow_session_interruption=</b><em>"choice"</em><b>;</b></p>
+ If <b>choice</b> is set to "yes", then another source will be able to interrupt an existing play session and start a new one.
+ When set to "no" (the default), other devices attempting to interrupt a session will fail, receiving a busy signal.
- <p><b>session_timeout=</b><em>120</em><b>;</b></p>
- Comment Here
+ <p><b>session_timeout=</b><em>seconds</em><b>;</b></p>
+ If a play session has been established and the source disappears without warning (such as a device going out of range of a network)
+ then wait for <em>seconds</em> seconds before ending the session. Once the session has terminated, other devices can use it.
+ The default is 120 seconds.
<p><b>"ALSA" SETTINGS</b></p>
- These are the settings available within the <b>alsa</b> group:
+ <p>These settings are for the ALSA back end, used used to communicate with audio output devices in the ALSA system.
+ (By the way, you can use tools such as <b>alsamixer</b> or <b>aplay</b> to discover what devices are available.)
+ Use these settings to select the output device and the mixer control to be used to control the output volume.
+ You can additionally set the desired size of the output buffer and you can adjust overall latency. Here are the <b>alsa</b> group settings:</p>
- <p><b>output_device=</b><em>"default"</em><b>;</b></p>
- Comment Here
+ <p><b>output_device=</b><em>"output_device"</em><b>;</b></p>
+ Use the output device called <em>output_device</em>. The default is the device called "device".
- <p><b>mixer_type=</b><em>"software"</em><b>;</b></p>
- "software" or "hardware"
+ <p><b>mixer_control_name=</b><em>"name"</em><b>;</b></p>
+ Specify the <em>name</em> of the mixer control to be used by shairport-sync to control the volume.
+ The mixer control must be on the mixer device, which by default is the output device.
+ If you do not specify a mixer control name, shaiport-sync will control the volume in software.
- <p><b>mixer_device=</b><em>"default"</em><b>;</b></p>
- actually, the mixer default is whatever the output_device is. Normally you wouldn't have to use this.
+ <p><b>mixer_type=</b><em>"mixer_type"</em><b>;</b></p>
+ This setting is deprecated and will be removed soon. If you wish to use a mixer control to control the volume, then set <em>mixer_type</em> to "hardware".
+ The default is "software".
- <p><b>mixer_control_name=</b><em>"PCM"</em><b>;</b></p>
- the name of the mixer to use -- there is no default.
+ <p><b>mixer_device=</b><em>"mixer_device"</em><b>;</b></p>
+ By default, the mixer is assumed to be output_device is. Use this setting to specify a device other than the output device.
- <p><b>audio_backend_latency_offset=</b><em>0</em><b>;</b></p>
- Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+ <p><b>audio_backend_latency_offset=</b><em>offset</em><b>;</b></p>
+ Set this <em>offset</em>, in frames, to compensate for a fixed delay in the audio back end.
+ For example, if the output device delays by 100 ms, set this to -4410.
- <p><b>audio_backend_buffer_desired_length=</b><em>6615</em><b>;</b></p>
- If set too small, buffer underflow occurs on low-powered machines. Too long and the response times with software mixer become annoying.
+ <p><b>audio_backend_buffer_desired_length=</b><em>length</em><b>;</b></p>
+ Use this to set the desired number frames to be in the output device's hardware output buffer.
+ The default is 6,615 frames, or 0.15 seconds. If set too small, buffer underflow may occur on low-powered machines.
+ If too large, the response times when using a software mixer become annoying, or it may exceed the hardware buffer size.
+ It may need to be larger on low-powered machines performing other tasks, such as processing metadata.
<p><b>"PIPE" SETTINGS</b></p>
- These are the settings available within the <b>pipe</b> group:
+ <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>
+ <p>Use the <em>name</em> 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 <b>aplay</b>. The <em>audio_backend_latency_offset</em> affects precisely when the first audio packet is sent
+ and the <em>audio_backend_buffer_desired_length</em> setting affects the nominal output buffer size.</p>
+ <p>These are the settings available within the <b>pipe</b> group:</p>
- <p><b>audio_backend_latency_offset=</b><em>0</em><b>;</b></p>
- Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+ <p><b>name=</b><em>"/path/to/pipe"</em><b>;</b></p>
+ 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.
+
- <p><b>audio_backend_buffer_desired_length=</b><em>44100</em><b>;</b></p>
- Comment Here
+ <p><b>audio_backend_latency_offset=</b><em>offset_in_frames</em><b>;</b></p>
+ Packets of audio frames are written to the pipe synchronously -- that is, they are written to at exactly the time they should be played.
+ You can offset the time of initial audio output relative to its nominal time using this setting.
+ For example to send an audio stream to the pipe 100 milliseconds before it is due to be played, set this to -4410.
+
+
+
+ <p><b>audio_backend_buffer_desired_length=</b><em>buffer_length_in_frames</em><b>;</b></p>
+
+ 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 the pipe.
+ For example, if you send the first packet of audio exactly when it is due and, using a <em>audio_backend_buffer_desired_length</em> setting of 44100,
+ send subsequent packets of audio a second before they are due to be played, they will be buffered in the pipe reader's buffer, giving it a nominal buffer size of 44,100 frames.
+ Note that if the pipe reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually --
+ Shairport Sync performs no stuffing or interpolation when writing to a pipe.
- <p><b>name=</b><em>"/path/to/pipe"</em><b>;</b></p>
- there is no default pipe name for the output
<p><b>"STDOUT" SETTINGS</b></p>
- These are the settings available within the <b>stdout</b> group:
+ <p>These settings are for the STDOUT backend, used to route audio to standard output ("stdout").
+ The audio is in raw CD audio format: PCM 16 bit little endian, 44,100 samples per second, stereo.</p>
+ <p>There are two settings affecting timing that might be useful if the stdout reader is, for example,
+ a program to play an audio stream such as <b>aplay</b>. The <em>audio_backend_latency_offset</em> affects precisely when the first audio packet is sent
+ and the <em>audio_backend_buffer_desired_length</em> setting affects the nominal output buffer size.</p>
+ <p>These are the settings available within the <b>stdout</b> group:</p>
- <p><b>audio_backend_latency_offset=</b><em>0</em><b>;</b></p>
- Set this offset to compensate for a fixed delay in the audio back end. E.g. if the output device delays by 100 ms, set this to -4410.
+ <p><b>audio_backend_latency_offset=</b><em>offset_in_frames</em><b>;</b></p>
+
+ Packets of audio frames are written to stdout synchronously -- that is, they are written at exactly the time they should be played.
+ You can offset the time of initial audio output relative to its nominal time using this setting.
+ For example to send an audio stream to stdout 100 milliseconds before it is due to be played, set this to -4410.
+
- <p><b>audio_backend_buffer_desired_length=</b><em>44100</em><b>;</b></p>
- Comment Here
+ <p><b>audio_backend_buffer_desired_length=</b><em>buffer_length_in_frames</em><b>;</b></p>
+
+ 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 stdout.
+ For example, if you send the first packet of audio exactly when it is due and, using a <em>audio_backend_buffer_desired_length</em> 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 stdout reader consumes audio faster or slower than they are supplied, the buffer will empty or overflow eventually --
+ Shairport Sync performs no stuffing or interpolation when writing to stdout.
+
+
projects / thirdparty / shairport-sync.git / commitdiff
