shairport-sync(7)
β¨ shairport-sync π
okay bestie, welcome to the manual page for shairport-sync β it lives in the Miscellaneous Information Manual, section 7, and it's literally the moment your whole music setup levels up. grab a snack, we're doing this. π
π NAME π
shairport-sync β Synchronised Audio Player for iTunes / AirPlay. yes, that's the whole vibe. π
π SYNOPSIS π
shairport-sync [-djvuw] [-a name] [-A latency] [-B command] [-c
configurationfile] [-E command] [--get-cover-art] [--logOutputLevel] [-L
latency] [-m backend] [--meta-dir=directory] [-o backend]
[--password=secret] [-r threshold] [--statistics] [-S mode] [-t timeout]
[--tolerance=frames] [-- audio_backend_options]
shairport-sync -k
shairport-sync -h
shairport-sync -V
like, four whole ways to summon it. pick your fighter. π
π DESCRIPTION π
Shairport Sync plays audio streamed from iTunes or from an AirPlay device to an ALSA-compatible audio output device (available on Linux and FreeBSD), to a "sndio" output device (available on OpenBSD, FreeBSD and Linux), to a PulseAudio output stream or to Jack Audio. so many doors, all of them open. πͺβ¨
Shairport Sync offers full audio synchronisation. and bestie, what that means is: audio is played on the output device at exactly the time specified by the audio source. so if a bunch of devices are playing the same stream at the same time, all the outputs stay in synchrony with one another. no drift, no chaos, no one being 0.3 seconds behind. this lets multiple devices play the same source without getting out of step with one another, enabling, for example, simultaneous multi-room operation. whole house, one song, zero fighting. π₯
Shairport Sync can stream synchronised audio to a unix pipe or to standard output, or to audio systems that do not provide timing information. this could perhaps be described as partial audio synchronisation, where synchronised audio is provided by Shairport Sync, but what happens to it in the subsequent processing chain, before it reaches the listener's ear, is outside the control of shairport-sync. it's giving "i did my part, the rest is on y'all." π«Ά
Shairport Sync can be compiled to stream metadata, including cover art, to a pipe or socket. β¨
Shairport Sync can be compiled to offer a standard MPRIS interface, a "native" D-Bus interface and an MQTT client interface. through these interfaces, it can provide metadata, including cover art, and can offer remote control of the audio source. iconic behaviour honestly. π
Settings can be made using the configuration file (recommended for all new installations) or by using command-line options.
The name of the Shairport Sync executable is shairport-sync. Both names are used in these man pages. yes it's the same girl, two nicknames. π
πΈ CONFIGURATION FILE SETTINGS πΈ
You should use the configuration file for setting up Shairport Sync. not optional-bestie behaviour, it's the recommended path. This file is usually shairport-sync.conf and is generally located in the System Configuration Directory, which is normally the /etc directory in Linux or the /usr/local/etc directory in BSD unixes. You may need to have root privileges to modify it. yes, root. the big one. π
(Note: Shairport Sync may have been compiled to use a different configuration directory. You can determine which by performing the command $ shairport-sync -V. One of the items in the output string is the value of the sysconfdir, i.e. the System Configuration Directory.)
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:
general = {
name = "Mike's Boombox";
password = "secret";
output_backend = "alsa";
};
alsa = {
output_device = "hw:0";
mixer_control_name = "PCM";
};
Most settings have sensible default values, so -- as in the example above -- users generally only need to set (1) the service name, (2) a password (if desired) and (3) the output device. If the output device has a mixer that can be used for volume control, then (4) the mixer name should be specified. It is important to do this if the mixer exists. Otherwise, the maximum output from the output device will be whatever setting the mixer happens to have, which will be a matter of chance and which could be very low or even silent. π do not let your speakers be silent by accident, that's so not the vibe.
A sample configuration file with all possible settings, but with all of them commented out, is installed at shairport-sync.conf.sample, within the System Configuration Directory -- /etc in Linux, /usr/local/etc in BSD unixes. a whole menu, everything crossed out. cute. π
To retain backwards compatibility with previous versions of shairport-sync you can use still use command line options, but any new features, etc. will be available only via configuration file settings. so the old ways work, but they don't get the new stuff. lowkey sad for the CLI girlies. π
The configuration file is processed using the libconfig library -- see http://www.hyperrealm.com/libconfig/libconfig_manual.html.
π "GENERAL" SETTINGS π
These are the settings available within the general group:
name="service_name";β Use this service_name to identify this player in iTunes, etc.
The following substitutions are allowed: %h for the computer's hostname, %H for the computer's hostname with the first letter capitalised (ASCII only), %v for the shairport-sync version number, e.g. "3.3.6" and %V for the shairport-sync version string, e.g. "3.3.6-OpenSSL-Avahi-ALSA-soxr-metadata-sysconfdir:/etc".
The default is "%H", which is replaced by the hostname with the first letter capitalised.
password="password";β Require the password password to connect to the service. If you leave this setting commented out, no password is needed. it's giving "come on in" energy. πinterpolation="mode";β Interpolate, or "stuff", the audio stream using the mode. Interpolation here refers to the process of adding or removing frames of audio to or from the stream sent to the output device to keep it exactly synchronised with the player. The"basic"mode is normally almost completely inaudible. The alternative mode,"soxr", is even less obtrusive but requires much more processing power. For this mode, support for libsoxr, the SoX Resampler Library, must be selected when shairport-sync is compiled. The default setting is"auto", which will choose"soxr"if support for it has been compiled into the build of Shairport Sync and if the CPU is fast enough. Otherwise,"basic"stuffing will be chosen. π§ auto is out here making decisions for you and honestly? slay.output_backend="backend";β shairport-sync has a number of modules of code ("backends") through which audio is output. Normally, the first audio backend that works is selected. This setting forces the selection of the specific audio backend. Perform the commandshairport-sync -hto get a list of available audio backends -- the default is the first on this list. Only the"alsa","sndio"and"pa"backends support synchronisation. β οΈ note that, bestie, only those three keep the sync.mdns_backend="backend";β shairport-sync has a number of modules of code ("backends") for interacting with the mDNS service to be used to advertise itself. Normally, the first mDNS backend that works is selected. This setting forces the selection of the specific mDNS backend. The default is"avahi". Perform the commandshairport-sync -hto get a list of available mDNS modules.port=portnumber;β Use this to specify the portnumber shairport-sync uses to listen for service requests from iTunes, etc. The default is port5000.udp_port_base=portnumber;β When shairport-sync starts to play audio, it establises three UDP connections to the audio source. Use this setting to specify the starting portnumber for these three ports. It will pick the first three unused ports starting from portnumber. The default is port6001.udp_port_range=range;β Use this in conjunction with the previous setting to specify the range of ports that can be checked for availability. Only three ports are needed. The default is100, thus 100 ports will be checked from port 6001 upwards until three are found.drift_tolerance_in_seconds=seconds;β Allow playback to drift up to seconds out of exact synchronization before attempting to correct it. The default is0.002seconds, 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 thestatisticssetting to monitor correction levels. Corrections should not greatly exceed net corrections. This setting replaces the deprecateddriftsetting.resync_threshold_in_seconds=threshold;β Resynchronise if timings differ by more than threshold seconds. If the output timing differs from the source timing by more than the threshold, output will be muted and a full resynchronisation will occur. The default threshold is0.050seconds, i.e. 50 milliseconds. Specify0.0to disable resynchronisation. This setting replaces the deprecatedresync_thresholdsetting.ignore_volume_control="choice";β Set this choice to"yes"if you want the volume to be at 100% no matter what the source's volume control is set to. This might be useful if you want to set the volume on the output device, independently of the setting at the source. The default is"no".volume_range_db=dBvalue;β Use this dBvalue to reduce or increase the attenuation range, in decibels, between the minimum and maximum volume.
For example, if a mixer has a minimum volume of -80 dB and a maximum of +20 dB, you might wish to use only 60 dB of the 100 dB available. 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.
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 30 dB. 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 30. Using it in this case gives the volume control a much more useful range of settings. π
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. If you specify a volume range greater than the range of the mixer, software attenuation and hardware attenuation will be combined to give the specified range.
If you omit this setting, the native range of the mixer is used.
volume_max_db=dBvalue;</p> ποΈ
This sets the maximum output level for the hardware mixer, if you're using one. And if you're not using a hardware mixer, this instead sets the max setting allowed in the software mixer β which has an attenuation range from 0.0 dB all the way down to -96.3 dB. Slay.
volume_control_profile="choice";</p> π
An advanced one, bestie β this decides how the AirPlay volume maps onto the mixer volume.
"standard"β the default! Volume moves faster at lower volumes and slower at higher volumes."flat"β volume changes at the same rate at all volume levels.
Pick your fighter.
volume_range_combined_hardware_priority= "choice";</p> π₯
Advanced setting time π β this is about how you combine the hardware attenuator with software attenuation so you get a bigger attenuation range than the hardware can manage on its own.
"yes"β when attenuation is needed, the hardware attenuator gets used first, in preference. If you need more attenuation than it can give, the hardware attenuator is set to its greatest attenuation and software attenuation is added on top.
So like, if 40 dB of attenuation is required and the hardware attenuator maxes out at 30 dB? Then hardware gives you 30 dB of attenuation and 10 dB of software attenuation gets added. Math! β¨
β οΈ The catch, and it's a real one: certain hardware attenuators will mute at their greatest attenuation, so they can't be combined with software attenuation this way.
"no"β software attenuation is used to bring the remaining attenuation required into the range the hardware attenuator offers. This is the default.
run_this_when_volume_is_set= "/full/path/to/application/and/args";</p> π«Ά
Here's where you name a program and its arguments to run whenever the volume is set or changed. Be careful β include the full path to the application, okay? It has to be marked as executable, and if it's a script, its first line must begin with the standard shebang #!/bin/... as appropriate.
The desired AirPlay volume is appended to the end of the command line β so leave a space at the end of the command line you specify here if you want it treated as an extra argument. AirPlay volume goes from 0.0 to -30.0, and -144.0 means "mute". Noted π
regtype="regTypeString";</p> π
Advanced setting alert β this sets the service type and transport to be advertised by Zeroconf/Bonjour. Default is "_raop._tcp".
playback_mode="mode";</p> π§
The mode can be "stereo", "mono", "reverse stereo", "both left" or "both right". Default is "stereo".
Heads up: dither will be added to the signal in mono mode. That's just how it is, fr fr.
alac_decoder="decodername";</p> π
This one can be "hammerton" or "apple". It's an advanced setting that lets you pick between the original Shairport decoder by David Hammerton, or the Apple Lossless Audio Codec (ALAC) decoder written by Apple.
Lowkey important: for this to work, Shairport Sync must have been compiled with the configuration setting "--with-apple-alac", and the Apple ALAC decoder library must be present. No library, no vibes. π
interface="name";</p> π¦
Use this advanced setting if you want to confine Shairport Sync to the named interface. Leave it commented out to get the default behaviour.
audio_backend_latency_offset_in_seconds= offset_in_seconds;</p> β±οΈ
Set offset_in_seconds 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.
audio_backend_buffer_desired_length_in_seconds= length_in_seconds;</p> π
Use length_in_seconds to set the desired length of the queue of audio frames in the backend's output buffer.
The default is 0.15 seconds for the ALSA backend, 0.35 seconds for the PA backend, and one second for all other backends.
Now listen β if this value is set too small, underflow may occur on low-powered machines. If set too large, the response times to the volume control may become excessive, or it may exceed the backend's buffer size. And it may need to be larger on low-powered machines that are also performing other tasks, such as processing metadata. It's giving delicate balance π.
audio_backend_buffer_interpolation_threshold_in_seconds= time_in_seconds;</p> π§
This is an advanced feature, bestie. If the length of the audio backend buffer size drops below this, it's a sign that shairport sync cannot process frames of audio quickly enough. If this threshold is reached, shairport sync will stop using time-consuming interpolation like soxr to avoid underruns.
audio_backend_silent_lead_in_time= lead_in_time_in_seconds;</p> πΈ
This is an advanced setting. Use lead_in_time_in_seconds to set the desired length of the period of silence β a "silent lead-in" β played before a play session begins.
The purpose of this silent lead-in is to give the backend sufficient time to prepare for operation, and to make an estimate (and, importantly, to correct the estimate) of the exact time at which to begin playing audio to achieve initial synchronisation. The value can be from 0.0 up to a maximum of either 4.0 seconds. The actual duration will be close to the setting but cannot exceed the latency set by the client, usually 2 seconds or a little more.
β οΈ If the value chosen is too short for synchronised backends such as the ALSA, sndio or PA backends, then audio will not be synchronised correctly at the start of play. π
The default is to have a silent lead-in of approximately the same time as the latency set by the client.
dbus_service_bus= "bus_name";</p> β
If shairport sync is compiled with the D-Bus interface, it can offer it on the "system" or the "session" D-Bus "bus". Use this to specify which. The default is to use the "system" bus.
mpris_service_bus= "bus_name";</p> β
If shairport sync is compiled with the MPRIS interface, it can offer the service on the "system" or the "session" D-Bus "bus". Use this to specify which. The default is to use the "system" bus.
β¨ "SESSIONCONTROL" SETTINGS β¨
Okay this whole section is about controlling the vibes of a session β what runs when, and how long stuff sticks around. Iconic behaviour, honestly.
run_this_before_play_begins="/path/to/application and args";</p> π¬
Here you can specify a program and its arguments that will be run just before a play session begins. 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 shebang #!/bin/... as appropriate.
run_this_after_play_ends="/path/to/application and args";</p> π¬
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 shebang #!/bin/... as appropriate.
run_this_before_entering_active_state="/path/to/application and args";</p> π
Here you can specify a program and its arguments that will be run just before shairport-sync goes active.
Shairport Sync goes "active" when a play session starts. When the play session ends, the system will stay active until the time specified in the active_state_timeout setting elapses. If a new play session starts before that, the system will remain active. Otherwise, the system will go inactive.
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 shebang #!/bin/... as appropriate.
run_this_after_exiting_active_state="/path/to/application and args";</p> π¬
Here you can specify a program and its arguments that will be run just after shairport-sync goes inactive (see the previous entry for an explanation of the idea). 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 shebang #!/bin/... as appropriate.
active_state_timeout=seconds;</p> β³
After a play session has ended, the system will remain active for seconds seconds. If a new play session starts before this time has elapsed, the system will remain active. However, if no new session starts in the interval, the system will go inactive at the end of it. The default is 10 seconds.
run_this_if_an_unfixable_error_is_detected="/path/to/application and args";</p> π¨
Here you can specify a program and its arguments that will be run if the system detects an unfixable error. At present, there are two types of unfixable errors:
- A play session cannot be terminated.
- An output device has "stalled" β that is, if an output device refuses to accept any more output frames.
Although the first problem could, in principle, be fixed by restarting Shairport Sync, it is usually caused by a malfunctioning output device. Typically, the most reliable way to recover from either of these errors is to reboot the entire machine. π
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 shebang #!/bin/... as appropriate.
wait_for_completion="choice";</p> βΈοΈ
Set choice to "yes" to make shairport-sync wait until the programs specified in the run_this_... settings have completed execution before continuing. The default is "no".
allow_session_interruption="choice";</p> π
ββοΈ
If choice 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. Respect the queue, bestie.
session_timeout=seconds;</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 the number of seconds specified before ending the session. Once the session has terminated, other devices can use it. The default is 120 seconds.
β¨ "ALSA" SETTINGS β¨
okay so this whole group is for the ALSA back end β that's the bit that talks to your audio output devices in the ALSA system. π (psst: you can use tools like alsamixer or aplay to go find out what devices you actually have, iykyk.) These settings are how you pick your output device, pick the mixer control that's gonna run your output volume, set the size of the output buffer you want, and adjust overall latency. Here's the whole alsa group, bestie:
output_device="output_device";β use the output device literally called output_device. Default is the device called"default".mixer_control_name="name";β names the mixer control thatshairport-syncuses to control the volume. Heads up: that mixer control has to live on the mixer device, which by default is the output device. And if you don't name a mixer control at all,shairport-syncwill just adjust the volume in software instead. ποΈmixer_device="mixer_device";β by default the mixer is assumed to be output_device. Use this setting when you want to point at a device that isn't the output device.output_rate=frame rate;β sets the frame rate that gets output to the ALSA device. Allowable values are"auto"(the default),44100,88200,176400and352800. The device must be able to accept the rate you pick. fr, there's no particular reason to use anything other than44100if it's available, and if"auto"is selected, the lowest of these rates that's available β starting at44100β gets chosen.output_format="format";β sets the format used to send data to the ALSA device. Allowable values are"auto"(default),"U8","S8","S16","S24","S24_3LE","S24_3BE"or"S32". Again, your device must be capable of accepting the format you specify.
quick decode for you: "S" means signed, "U" means unsigned, BE means big-endian and LE means little-endian. Except where it's stated (using *LE or *BE), the endianness matches that of the processor. The default is "S16".
Now, if you're running a hardware mixer, S16 is totally fine β the audio passes through Shairport Sync unmodified except for interpolation β but any of the higher-resolution formats are okay too. If you're on the software mixer, use 32- or 24-bit if your device can handle it, so you get the lowest possible levels of dither. And the "auto" setting? That makes Shairport Sync choose the highest resolution available. π
disable_synchronization="no";β this one is an advanced setting and it's for debugging only. Set it to"yes"to disable synchronization. Default is"no".
β οΈ bestie if you use this to disable synchronisation, then sooner or later you will hit audio glitches from audio buffer overflow or underflow. no cap.
period_size=number;β optional advanced setting, sets the alsa period size near to this value.buffer_size=number;β optional advanced setting, sets the alsa buffer size near to this value.use_mmap_if_available="yes";β optional advanced setting that controls whether MMAP-based output is used to communicate with the DAC. Default is"yes".mute_using_playback_switch="no";β advanced setting, default is"no". If you set it to"yes", hardware mute will be used wherever it's available. Set it to"no"to stop the hardware mute from being used.
If Shairport Sync is sharing the output device with other applications, it's best to leave this at "no" so you stay compatible with those apps. π«Ά
Another motivation for this is to let the ALSA function call snd_mixer_selem_set_playback_switch_all be avoided β it's incorrectly implemented on certain soundcards, including the emulated card in VMWare Fusion 8.5. π
maximum_stall_time=seconds;β if an output device fails to accept any audio frames for longer than the time, in seconds, specified here (0.2seconds by default), it's considered to have malfunctioned. That will result in therun_this_if_an_unfixable_error_is_detectedprogram, if any, being called.
Implemented for the ALSA back end only.
disable_standby_mode="never";β Shairport Sync has a "Disable Standby" feature to eliminate certain faint-but-annoying audible pops and clicks. When activated, it stops an output device from entering standby mode, and that minimises standby/busy transitions, which can sometimes be heard. Use this setting to control when the Disable Standby feature is active:"never"means it will never be activated,"always"means it'll be active as soon asshairport-syncstarts running, and"auto"means it'll be active whileshairport-syncis in the"active"state.
Shairport Sync goes "active" when a play session starts. When the play session ends, the system stays active until the time specified in the active_state_timeout setting elapses. If a new play session starts before that happens, the system remains active. Otherwise, the system goes inactive. π¦
πΈ "SNDIO" SETTINGS πΈ
These ones are for the SNDIO back end, used to communicate with audio output devices in the SNDIO system. π
device="snd/0";β optional setting for the name of the output device, e.g."snd/0". The default is to use the SNDIO system's default.rate=44100;β optional setting for the output rate in frames per second. Valid rates are44100,88200,176400or352800. Your output device must be able to accept data at the rate you specify. Default is44100.format="S16";β optional setting for the output format. Allowable values are"U8","S8","S16","S24","S24_3LE","S24_3BE"or"S32". The device must be capable of accepting the format you specify.
Same decoder ring as before: "S" means signed, "U" means unsigned, BE means big-endian and LE means little-endian. Except where stated (using *LE or *BE), the endianness matches that of the processor. The default is "S16".
Since the SNDIO backend doesn't use a hardware mixer for volume control, dither gets introduced into the output if it's less than full volume. So (unless you're ignoring the volume control setting) consider using 32- or 24-bit output if your device can do it, to get the lowest possible levels of dither. π§
π please note that 32- or 24-bit has not been extensively tested on SNDIO.
round=value;β optional advanced setting for the period size of the SNDIO channel. If you omit it, a SNDIO system default value will be used.bufsiz=value;β optional advanced setting for the buffer size of the SNDIO channel. If you omit it, a SNDIO system default value will be used.
π "PA" SETTINGS π
These settings are for the new PulseAudio backend. π
application_name="Shairport Sync";β use this to set the name that appears in the Sounds "Applications" tab when Shairport Sync is active. The default is the name"Shairport Sync".
π "PIPE" SETTINGS π
These ones are for the PIPE backend, which routes audio to a named unix pipe. The audio is in raw CD audio format: PCM 16 bit little endian, 44,100 samples per second, interleaved stereo. πΆ
name="/path/to/pipe";β specifies the name and location of the pipe. The pipe gets created and opened whenshairport-syncstarts up, and gets closed upon shutdown. Frames of audio are sent to the pipe in packets of352frames and get discarded if the pipe doesn't have a reader attached. The sender will wait for up to five seconds for a packet to be written before discarding it. β³
β "STDOUT" SETTINGS β
There are no settings for the STDOUT backend. that's it, that's the section. πβ¨
π "AO" SETTINGS π
There are no configuration file settings for the AO backend. also iconic for having nothing to say. π
π¦ "METADATA" SETTINGS π¦
shairport-sync can process metadata provided by the source β stuff like Track Number, Album Name, cover art, etc. β and it can also provide additional metadata such as volume level, pause/resume, etc. It sends the metadata to a pipe, by default /tmp/shairport-sync-metadata. To process metadata, shairport-sync must have been compiled with metadata support included. You can check that it was by running the command $ shairport-sync -V β the identification string will contain the word metadata. π
Please note that different sources provide different levels of metadata. Some provide a lot; some provide almost none. π
The metadata group of settings lets you enable metadata handling and control certain aspects of it:
enabled="choice";β set the choice to"yes"to enableshairport-syncto look for metadata from the audio source and to forward it, along with metadata generated byshairport-syncitself, to the metadata pipe. The default is"no".include_cover_art="choice";β set the choice to"yes"to enableshairport-syncto look for cover art from the audio source and to include it in the feed to the metadata pipe. You must also enable metadata (see above). One reason for not including cover art is that the images can sometimes be very large and may delay transmission of subsequent metadata through the pipe. The default is"no".pipe_name="filepathname";β specify the absolute path name of the pipe through which metadata should be sent. The default is/tmp/shairport-sync-metadata.socket_address="hostnameOrIP";β if hostnameOrIP is set to a host name or an IP address, UDP packets containing metadata will be sent to this address. May be a multicast address. Additionally,socket-portmust be non-zero andenabledmust be set to"yes".socket_port=port;β ifsocket_addressis set, use port to specify the port to send UDP packets to. Must not be zero.socket_msglength=65000;β the maximum packet size for any UDP metadata. This must be between500or65000. The default is500.
π©Ί "DIAGNOSTICS" SETTINGS π©Ί
statistics="setting"β turn the stats output on ("yes") or off ("no"). Where do these stats go? To the system log, or to STDERR if you picked the-ucommand line option π«Ά. Default? disabled, bestie. No stats for you unless you ask.log_verbosity=0β this one controls how much debug tea gets spilled into the system log (orSTDERRagain, if-uis on the menu β).0= literally zero debug info,3= the most debug info you can get. Default is0, so it's giving silence until you turn it up π.
β¨ OPTIONS β¨
okay so this section is all about the command-line options that ship with shairport-sync π
Note: if you're setting up shairport-sync for the very first time, or you're updating an existing install, pleaseeee use the configuration file settings we talked about above π. Most of the command-line options down here are just copies of those config settings, kept around so older installations don't break. Backward compatibility, we love her π.
A lot of these options come with sensible defaults already baked in, so honestly you can just ignore most of them, no cap. Peep the EXAMPLES section for typical usages π.
So there are two kinds of command-line options for shairport-sync:
- regular program options
- audio backend options
Program options always come first π₯, then any audio backend options follow, and those are preceded by a -- symbol π.
π§ PROGRAM OPTIONS π§
These are the options used by shairport-sync itself, bestie.
-a service name,--name=service nameβ use this service name to identify this player in iTunes and friends πΈ. Here's the substitution menu, and yes they're all allowed:%hβ the computer's hostname%Hβ the computer's hostname but with the first letter capitalised (ASCII only, okurrr)%vβ theshairport-syncversion number, like"3.0.1"%Vβ theshairport-syncversion string, like"3.0.1-OpenSSL-Avahi-ALSA-soxr-metadata-sysconfdir:/etc"
The default is "%H", which gets swapped out for the hostname with the first letter capitalised π.
-B program,--on-start=programβ run program right when playback is about to begin π¬. Give it the full path to the program, e.g./usr/bin/logger. You can absolutely use executable scripts too, but they must have the right shebang (#!/bin/shin the headline π).
If you want shairport-sync to actually wait for the command to finish before it starts playing, go ahead and also select the -w option π«‘.
-c filename,--configfile=filenameβ read configuration settings from filename π. Default is to read them fromshairport-sync.confin the System Configuration Directory β that's/etcon Linux and/usr/local/etcon BSD unixes π». Wanna know about the config settings? Scroll up to the "Configuration File Settings" section, bestie.-d,--daemonβ tellsshairport-syncto demonise itself π. It'll write its Process ID (PID) to a file, usually at/var/run/shairport-sync/shairport-sync.pid, which the-k,-Dand-Roptions use later to find the daemon again π. Also check the-joption. Only available ifshaiport-syncwas compiled withlibdaemonsupport.-E program,--on-stop=programβ run program when playback has ended π. Full path to the program, e.g./usr/bin/logger. Executable scripts work too, but again they need the correct shebang (#!/bin/shin the headline π).
If you want shairport-sync to wait until the command has completed before carrying on, select the -w option as well π«Ά.
--get-coverartβ this option requires the--meta-diroption to be set, and it letsshairport-syncrequest cover art from the source and send it through the metadata pipe π¨.
Heads up: cover art data can be very large, and it might put wayyy too much strain on your network π. Be careful, bestie.
-h,--helpβ print a short help message and exit π.-jβ tellsshairport-syncto demonise itself π. Unlike the-doption, it will not write a Process ID (PID) to a file β it just demonises itself (hence the"j", get it? π). Only available ifshaiport-syncwas compiled withlibdaemonsupport.-k,--killβ kill theshairport-syncdaemon and exit π. (This requires that the daemon has written its PID to an agreed file β see the-doption. Only available ifshaiport-syncwas compiled withlibdaemonsupport.)--logOutputLevelβ use this to log the volume level whenever the volume changes π. Could be useful if you're trying to figure out a good value for the maximum volume level. Not available as a configuration file setting, just so you know π«.-L,--latency=latencyβ sets the default latency, in frames, for audio coming from an unidentified source, or from an iTunes Version 9 or earlier source β±οΈ. The standard value for the default latency is88,200frames, where there are44,100frames to the second.
Warning: this feature is deprecated and will be removed in a future version of shairport-sync π.
--meta-dir=directoryβ listen for metadata coming from the source and send it, along with metadata fromshairport-syncitself, to a pipe calledshairport-sync-metadatain the directory you specify π¬. If you also add the--get-cover-artthen cover art gets sent through the pipe too π¨. Peephttps://github.com/mikebrady/shairport-sync-metadata-readerfor a sample metadata reader π₯.-m mdnsbackend,--mdns=mdnsbackendβ force the use of the specified mDNS backend to advertise the player on the network π‘. The default is to try all mDNS backends until one works.-o outputbackend,--output=outputbackendβ force the use of the specified output backend to play the audio π΅. The default is to try the first one.-p port,--port=portβ listen for play requests on port π. The default is to use port5000.--password=secretβ require the password secret to be able to connect and stream to the service π.-r threshold,--resync=thresholdβ resynchronise if timings differ by more than threshold frames π. If the output timing differs from the source timing by more than the threshold, output gets muted and a full resynchronisation happens. The default threshold is2,205frames, i.e.50milliseconds. Specify0to disable resynchronisation entirely. This setting is deprecated and will be removed in a future version ofshairport-syncπ.--statisticsβ print some statistics to the standard output, or to the logfile if you're in daemon mode π.-S mode,--stuffing=modeβ stuff the audio stream using the mode π§Έ. "Stuffing" means the process of adding or removing frames of audio to or from the stream sent to the output device, so it stays exactly in sync with the player. The default mode,basic, is normally almost completely inaudible π€«. The alternative mode,soxr, is even less obtrusive but needs much more processing power π₯. For this mode, support forlibsoxr, the SoX Resampler Library, must be selected whenshairport-syncis compiled.-t timeout,--timeout=timeoutβ exit play mode if the stream disappears for more than timeout seconds β³. Here's the tea: whenshairport-syncplays an audio stream, it starts a play session and returns a busy signal to any other sources trying to use it. If the audio stream disappears for longer than timeout seconds, the play session gets terminated. If you specify a timeout of0,shairport-syncwill never signal that it's busy and won't stop other sources from "barging in" on an existing play session π³. Default value is120seconds.--tolerance=framesβ allow playback to be up to frames out of exact synchronization before it tries to correct it π―. The default is88frames, i.e.2ms. The smaller the tolerance, the more likely overcorrection is gonna happen. Overcorrection = when more corrections (insertions and deletions) are made than are strictly necessary to keep the stream in sync. Use the--statisticsoption to monitor correction levels π. Corrections should not greatly exceed net corrections. This setting is deprecated and will be removed in a future version ofshairport-syncπ.-uβ if you're runningshairport-syncfrom the command line and you want logs to show up there, use this option π». Otherwise, logs may go to the system log.-V,--versionβ print version information and exit π·οΈ.-v,--verboseβ print debug information to the system log, or toSTDERRif the-ucommand line option is also chosen π. Repeat up to three times to get more detail.-w,--wait-cmdβ wait for commands specified using-Bor-Eto complete before continuing execution βΈοΈ.
Okay bestie, this is the part where we talk about the audio backend β like, the actual place your music goes to get heard. Buckle up. π§β¨
π₯ AUDIO BACKEND OPTIONS π₯
So here's the tea: these command-line options get passed along to whichever audio backend you picked. They're introduced by a -- symbol β that's the little separator that keeps them from getting mixed up with your program options. The whole point of that -- is so the same option letters can be used as program options and as audio backend options without any ambiguity. Iconic, honestly. π
Now, in the ALSA backend, audio gets sent to an output device, and you pick which one with the -d option. The output level β aka the "volume" β is controlled using a level control that's associated with a mixer. And here's the plot twist: by default, that mixer is implemented inside shairport-sync itself, in software.
But if you want to use a hardware level control on a mixer that lives on the sound card, you specify the name of that mixer control with the -c option. And if the mixer isn't associated with the output device at all? Then bestie, you gotta tell it where to find the mixer using the -m option. Periodt. π
-ccontrolname β Use the level control called controlname on the hardware mixer for controlling volume. This is needed if the mixer type is specified, using the-toption, to behardware. There is no default. π-ddevice β Use the specified output device. You can specify a card, e.g.hw:0, and in that case the default output device on the card will be chosen. Or you can go specific and name a particular device on a card, e.g.hw:0,0. The default is the device nameddefault. β¨-mmixer β Use the specified hardware mixer for volume control. Use this to say where the mixer is to be found. For example, if the mixer is associated with a card β which is, like, usually the case β specify the card, e.g.hw:0. If (unusually!) the mixer is associated with a specific device on a card, specify the device, e.g.hw:0,1. The default is the device named in the-doption, if given, or the device nameddefault. π-tdevicetype β This option is deprecated and is ignored. π For your information (iykyk), its functionality has been automatically incorporated into the-coption β if you specify a mixer name with the-coption, it is assumed that the mixer is implemented in hardware.
β¨ EXAMPLES β¨
Here's a slightly contrived example, and yes the man page itself calls it contrived, so we're being honest here: πΈ
shairport-sync -d -a "Joe's Stereo" -S soxr -- -d hw:1,0 -m hw:1 -c PCM
Let's break it down, bestie. π«Ά
- The program will run in daemon mode (
-d) - It will be visible as "Joe's Stereo" (
-a "Joe's Stereo") - And it'll use the SoX Resampler Library-based stuffing (
-S soxr)
Then, the audio backend options following that -- separator specify that the audio will be output on output 0 of soundcard 1 (-d hw:1,0) and will take advantage of the same sound card's mixer (-m hw:1) using the level control named "PCM" (-c "PCM"). Chef's kiss. π
Now, the example above is slightly contrived on purpose β it's doing all that just to show off the -m option. Typically, output 0 is the default output of a card, so the output device could just be written -d hw:1, and then the mixer option would be totally unnecessary. Which gives you this much simpler command: π¦
shairport-sync -d -a "Joe's Stereo" -S soxr -- -d hw:1 -c PCM
π CREDITS π
Giving credit where it's due, because we are nothing if not grateful:
- Mike Brady developed
shairport-syncfrom the original Shairport by James Laird. π«‘ shairport-synccan be found athttps://github.com/mikebrady/shairport-sync. π- Shairport can be found at
https://github.com/abrasive/shairport. β
π COMMENTS π
This man page was written using xml2man(1) by Oliver Kurth. π
And that's a wrap on shairport-sync(7), bestie! π This page lives in the Manuals section, it's a User manual, and it's dated and versioned as shairport-sync(7) β so if you're ever lost, just remember: man 7 shairport-sync and I gotchu. π Stay slaying, keep your volume levels cute, and never forget your -- separator. Byeee! π¦β¨π
π¦ where this page comes from
- debian bookworm: shairport-sync 3.3.8-1+b2 Β· MIT
- ubuntu jammy: shairport-sync 3.3.8-1build1 Β· MIT
- ubuntu noble: shairport-sync 3.3.8-1build5 Β· MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms