Shairport Sync is an AirPlay audio player – it plays audio streamed from iTunes, iOS devices and other AirPlay sources such as Quicktime Player and ForkedDaapd, among others.
Audio played by a Shairport Sync-powered device stays synchronised with the source and hence with similar devices playing the same source. In this way, synchronised multi-room audio is possible without difficulty. (Hence the name Shairport Sync, BTW.)
- Shairport Sync does not support AirPlay video or photo streaming.
+ Shairport Sync runs on Linux and FreeBSD. It does not support AirPlay video or photo streaming.
-This is the unstable "development" branch. Changes and updates are incorporated into this branch quickly. To access the stable version, where changes are made after due time, please switch to the "master" branch.
-
+This is the stable "master" branch. Changes and updates are incorporated into this branch relatively slowly. To access the development version, where all the latest changes are made first, please switch to the "development" branch.
- **Please note that, between 2.8.4 and 2.8.5, there is a change in the standard ./configure arguments which you should not ignore!** If you are updating Shairport Sync from a version that is 2.8.4 or older, please read the [UPDATING](https://github.com/mikebrady/shairport-sync/blob/master/UPDATING.md) page very carefully.
-
More Information
----------
- Shairport Sync works by using timing information and timestamps present in data coming from the audio source (e.g. an iPhone) to play audio at exactly the right time. It does this by monitoring and controlling the *latency* — the time-gap between when a sound frame is supposed to be played, as specified by its `timestamp`, and the time when it is actually played by the audio output device, usually a Digital to Audio Converter (DAC).
+ Shairport Sync works by using timing information and timestamps present in data coming from the audio source (e.g. an iPhone) to play audio at exactly the right time. It uses the information to monitor and control the *latency* — the time-gap between when a sound frame is supposed to be played, as specified by its `timestamp`, and the time when it is actually played by the audio output device, usually a Digital to Audio Converter (DAC).
The latency to be used is specified by the source when it negotiates with Shairport Sync. Most sources set a latency of exactly two seconds. Recent versions of iTunes and forkedDaapd use a latency of just over 2.25 seconds.
For information about changes and updates, please refer to the RELEASENOTES.md file in the distribution.
- Note: Historically, Shairport Sync has taken its settings from command line arguments. While this is still the case, it does not always work well across distributions. Accordingly, from version 2.4 onwards, Shairport Sync reads settings from the file `/etc/shairport-sync.conf`. Access to new features will only be provided via the settings file.
-
-Building And Installing the Development Version
+Building And Installing
---------------------
-
-The following procedures will build and install the `shairport-sync` application into your system.
+Shairport Sync may already be available as a package in your Linux distribution (search for `shairport-sync` – the package named `shairport` is a different program). Packages are available on recent versions of Debian, Ubuntu, Arch, OpenWrt and possibly more. If you wish to build and install the latest version of Shairport Sync on OpenWrt, Arch or Fedora platforms, please follow the appropriate instructions below. Limited support is also available for Mac OS X. Otherwise follow the General Build Instructions. Then, when the program has been installed, refer to the section on Configuring Shairport Sync that follows.
- **Note**
-
- The following procedures will install the `shairport-sync` application into your system. Before continuing, you should check to see if `shairport-sync` is already installed – you can use the command `$ which shairport-sync` to find where it is located, if installed. If it is installed you should delete it – you may need superuser privileges. After deleting, check again in case further copies are installed elsewhere.
- (If the existing installation of `shairport-sync` is where the new copy will be installed into, it will be overwritten; sometimes, however, the installation is to another location, so it is safer, initially, to delete previous versions manually.)
-
- **Ubuntu:**
- Personal Package Archives for Shairport Sync master and development branches are available at https://launchpad.net/~dantheperson. A `shairport-sync` installer package is available in Ubuntu 16.04.
-
- **Debian:**
- `shairport-sync` is in the Debian archive and is scheduled for release with Debian Stretch (9): https://tracker.debian.org/shairport-sync. A backport for Debian Jessie (8) may be provided given enough demand.
-
- **OpenWrt:**
- There is a Shairport Sync package in OpenWrt `trunk`. Also, there's an OpenWrt package at https://github.com/mikebrady/shairport-sync-for-openwrt, including one that builds back to `Barrier Breaker`.
+ **Remove Old Versions Of Shairport Sync**
- **Arch Linux:**
- Shairport Sync is available for `x86_64` and `i686` platforms in the Arch Linux Community Repository -- search for `shairport-sync`. See also https://www.archlinux.org/packages/.
+ You should check to see if `shairport-sync` is already installed – you can use the command `$ which shairport-sync` to find where it is located, if installed. If it is installed you should delete it – you may need superuser privileges. After deleting, check again in case further copies are installed elsewhere.
- An Arch Linux installation package, suitable for compilation on any platform, is available at [EliaCereda/shairport-sync-PKGBUILD](https://github.com/EliaCereda/shairport-sync-PKGBUILD).
+ **FreeBSD**
- **Mac OS X:**
- A [HomeBrew](http://brew.sh) package exists for Shairport Sync. With HomeBrew installed, Shairport Sync can be installed using the command `$brew install shairport-sync`. Note that the installation uses the `libao` library and so synchronisation is not available — playback glitches will occur occasionally, when the `ao` system's buffers overflow or underflow.
-To build Shairport Sync from sources on FreeBSD please refer to [FREEBSD.md](https://github.com/mikebrady/shairport-sync/blob/development/FREEBSD.md).
++To build Shairport Sync from sources on FreeBSD please refer to [FREEBSD.md](https://github.com/mikebrady/shairport-sync/blob/master/FREEBSD.md).
- **Fedora:**
- Please see the guide at [FEDORA.md](https://github.com/mikebrady/shairport-sync/blob/master/FEDORA.md).
+ **Determine The Configuration Needed**
- **Cygwin:**
- Please see the guide at [CYGWIN.md](https://github.com/mikebrady/shairport-sync/blob/master/CYGWIN.md).
+ 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:
+ ```
+ $ pactl info
+ Server String: unix:/run/user/1000/pulse/native
+ Library Protocol Version: 30
+ Server Protocol Version: 30
+ Is Local: yes
+ Client Index: 9
+ Tile Size: 65472
+ User Name: mike
+ Host Name: ubuntu
+ Server Name: pulseaudio
+ Server Version: 8.0
+ Default Sample Specification: s16le 2ch 44100Hz
+ Default Channel Map: front-left,front-right
+ Default Sink: alsa_output.pci-0000_02_02.0.analog-stereo
+ Default Source: alsa_input.pci-0000_02_02.0.analog-stereo
+ Cookie: 96f9:3e8d
+ $
+ ```
+ If PulseAudio in not installed, you'll get something like this:
+ ```
+ $ pactl info
+ -bash: pactl: command not found
+ $
+ ```
+ If your system does not use PulseAudio, then it is likely that it uses the Advanced Linux Sound Architecture (ALSA), so you should build Shairport Sync with the ALSA backend. By the way, many systems with PulseAudio also have ALSA (in fact, PulseAudio is effectively a client of ALSA); in those cases you should choose the PulseAudio backend.
- Sincere thanks to all package contributors!
+ If PulseAudio is not installed, there is no necessity to install it for Shairport Sync. In fact, Shairport Sync works better without it.
- **General Build Instructions**
- The following procedures will install the shairport-sync application into your system. Before continuing, you should check to see if shairport-sync is already installed – you can use the command `$ which shairport-sync` to find where it is located, if installed. If it is installed you should delete it – you may need superuser privileges. After deleting, check again in case further copies are installed elsewhere.
+ **Building**
To build Shairport Sync from sources on Debian, Ubuntu, Raspbian, etc. follow these instructions.
- `apt-get install build-essential git xmltoman` – these may already be installed.
- `apt-get install autoconf automake libtool libdaemon-dev libasound2-dev libpopt-dev libconfig-dev`
+ - `apt-get install libasound2-dev` for the ALSA libraries
+ - `apt-get install libpulse-dev` for the PulseAudio libraries
- `apt-get install avahi-daemon libavahi-client-dev` if you want to use Avahi (recommended).
- `apt-get install libssl-dev` if you want to use OpenSSL and libcrypto, or use mbed TLS otherwise.
-- `apt-get install libmbedtls-dev` if you want to use mbed TLS, or use OpenSSL/libcrypto otherwise. (You can still use PolarSSL with `apt-get install libpolarssl-dev` if you want to use PolarSSL, but it is deprecated as it's not longer being supported. It is suggested you use mbed TLS instead.)
-- `apt-get install libsoxr-dev` if you want support for libsoxr-based resampling. This library is in many recent distributions, including Jessie and Raspbian Jessie; if not, instructions for how to build it from source for Rasbpian/Debian Wheezy are available at [LIBSOXR.md](https://github.com/mikebrady/shairport-sync/blob/development/LIBSOXR.md).
+- `apt-get install libmbedtls-dev` if you want to use mbed TLS, or use OpenSSL/libcrypto otherwise. You can still use PolarSSL with `apt-get install libpolarssl-dev` if you want to use PolarSSL, but it is deprecated as it's not longer being supported. (It is suggested you use mbed TLS, where available. It doesn't seem to be in Raspbian at the time of writing, March 2017.)
- - `apt-get install libsoxr-dev` if you want support for libsoxr-based resampling. This library is in many recent distributions, including Jessie and Raspbian Jessie; if not, instructions for how to build it from source for Rasbpian/Debian Wheezy are available at [LIBSOXR.md](https://github.com/mikebrady/shairport-sync/blob/development/LIBSOXR.md).
++- `apt-get install libsoxr-dev` if you want support for libsoxr-based resampling. This library is in many recent distributions, including Jessie and Raspbian Jessie; if not, instructions for how to build it from source for Rasbpian/Debian Wheezy are available at [LIBSOXR.md](https://github.com/mikebrady/shairport-sync/blob/master/LIBSOXR.md).
If you wish to include the Apple ALAC decoder, you need install it first – please refer to the [ALAC](https://github.com/mikebrady/alac) repository for more information.
WiFi Issues
---------
--If you are using WiFi, you should ensure that WiFi power management is off. See [TROUBLESHOOTING](https://github.com/mikebrady/shairport-sync/blob/development/TROUBLESHOOTING.md) for more details.
++If you are using WiFi, you should ensure that WiFi power management is off. See [TROUBLESHOOTING](https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md) for more details.
Troubleshooting
---------------
-Version 3.1 [Forthcoming, under revision...]
++Version 3.1rc0
+ ====
+ Version 3.1 brings two new backends, optional loudness and convolution filters, improvements in non-synchronised backends, enhancements, stability improvements and bug fixes.
+
+ **New Features**
+ * A `sndio` backend gives Shairport Sync native fully synchronised output on OpenBSD and FreeBSD, thanks to the work of [Tobias Kortkamp (t6)](https://github.com/t6).
+ * A `pa` backend now allows Shairport Sync to provide synchronised output on PulseAudio-equipped systems -- many desktop Linuxes use PulseAudio as their sound manager.
+ * Optional loudness and convolution filters can be incorporated in the audio processing chain, thanks to the fantastic work of [yannpom](https://github.com/yannpom).
-* A volume-change program hook has been added to execute an application whenever the volume is changed.
++* A volume-change program hook `run_this_when_volume_is_set` has been added to the `general` settings stanza to execute an application whenever the volume is changed.
+
-**Perky Changes You Should Know About**
++**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.
+
+ **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.
+ * The Linux installer has been improved and simplified and a FreeBSD installer introduced.
+ * A new setting, `audio_backend_silent_lead_in_time`, allows you to set the duration of the period of silence played (the "silent lead-in") before a play session starts.
+ * A new command-line option, `--logOutputLevel`, allows you to output the volume levels to the log whenever they are changed. This may be useful during setup.
+ * Improvements have been made to the handling of large items of metadata over UDP.
+ * A new command line option, `-j`, demonizes Shairport Sync without creating a PID file.
+ * A new `alsa`-only setting, `mute_using_playback_switch`, is available for advanced use.
+ * Other minor enhancements.
+
+ **Bug Fixes**
+ * Stability improvements. More care has been taken (!) to make code thread-safe, resulting in improved stability.
+ * Conversion from stereo to mono has been fixed to avoid clipping while preserving full resolution. Thanks to [Robert Jones (RobDeBagel)](https://github.com/RobDeBagel) for bringing this to notice.
+ * Short intrusions of audio at the start of a new session from the end of the previous session have been eliminated.
+ * Many (many!) miscellaneous bugs fixed.
+
-Version 3.1.d24
-====
-**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.
-* 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.
-* A new general setting, for advanced use only, called `audio_backend_silent_lead_in_time` had been introduced to set the length of the silent lead-in time from 0.0 up to a maximum of either 4.0 seconds or approximately the latency, whichever is the lower.
-* It is now possible to read `stdout` from the on-start command to choose ALSA output device. This is a highly specialised facility (i.e. a kind of hack) and will hopefully be replaced by a more general solution. Thanks to [Cody Cutrer](https://github.com/ccutrer) for it.
-
-**Bug Fixes**
-* Fixed a typo in shairport.c, thanks to [Troy Liu](https://github.com/troyliu0105).
-
-Version 3.1.d22
-====
-**Bug Fix**
-* Before starting a play session, Shairport Sync sends a period of silence – a "silent lead-in" – to the backend to prepare it. The lead-in starts when the command to start a play session is received and ends when the first frame of audio is played. Normally, the lead-in time corresponds approximately to the latency set by the client – typically two seconds. Due to a bug, when playing to a non-synchronised backend, such as the `stdout` or `pipe` backends, Shairport Sync can introduce a silent lead-in that is much too long. This bug is fixed in 3.1.d22 and the silent lead-in time should now be roughly equal to the latency set by the client.
-
-**Enhancement**
-* Some parameters in the new PulseAudio back end are now settable -- the Application Name, the buffer length and a delay offset. More details later.
-
-Version 3.1.d21
+Version 3.0.2
====
**Bug Fixes**
-* If a fault was detected during initialisation of the ALSA subsystem and Shairport Sync attempted to terminate, sometimes it would hang up waiting indefinitely for a mutex to be unlocked. Unlocking is now done before attempting to terminate. This fixes the issue in #539. Thanks to [f3flight](https://github.com/f3flight) for the report.
-
-Version 3.1.d20
-====
-**Bug Fix**
-* Fixed bug whereby Shairport Sync was searching the wrong directory for the configuration file.
-Thanks to [hui13](https://github.com/hui13) for reporting this.
-* Also fixed typo in version -- (3.1d19 was mistyped 3.1d189!).
-
-Version 3.1.d19
-====
-**Enhancement**
-* Improvement in sending metadata over UDP.
-Sending metadata over UDP currently suffers from two main issues:
-The send buffer is left to system default, and consequently packets can be lost as Airplay clients send a lot of metadata;
-some metadata (typically the cover art) cannot be sent within a single IPv4 UDP packet because it is too large.
-These commits fix both issues by setting larger send buffer of 4MB and chunking any metadata with a new sub-protocol ("ssnc", "chnk", packet_ix, packet_counts, packet_tag, packet_type, chunked_data).
-Thanks to [Paul Guyot](https://github.com/pguyot) for this work.
-
-* A new command line option `-j` to demonize Shairport Sync without creating a PID file. (The "j" is from the "j" in "just daemonize".)
-* Small change in startup behaviour. Shairport Sync now reads the configuration file before executing the `-k` option.
-
-Version 3.1d16
-====
-**New Feature**
-* PulseAudio support. A new fully-synchronised PulseAudio back end has been developed. Use the `--with-pa` configuration option instead of `--with-pulseaudio`. Then, select the new PulseAudio back end with the command line option `-o pa`. At present, it takes no options and has quite a few settings hard wired. The existing PulseAudio back end, which is available using the `--with-pulseaudio` configuration option and which has no synchronisation, is deprecated and will be removed.
-
-PulseAudio is built in to many recent desktop versions of Linux to manage the system's audio and, up to now, Shairport Sync would not play well with it because the ALSA back end normally used with Shairport Sync requires exclusive access to the soundcard, thus interfering with PulseAudio. By using the new `pa` back end, Shairport Sync can share the existing PulseAudio infrastructure without difficulty. On Ubuntu, it shows up as a new "Application" in the Sound Settings window.
-
-If you are using the PulseAudio back end, note that Shairport Sync can not run as a system daemon that runs automatically from startup. Instead, you need to start it up after you log in. This is a limitation of the way PulseAudio is set up on desktops, and it is recommended that you don't change the setup.
-
-If you are trying this out on a virtual machine, you might have to turn off resynchronisation to get it to work.
-
-Your feedback is welcome – this is a work in progress!
-
-**Pesky Changes You Can't Ignore**
-
-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.
-
-
-Version 3.1d15
-====
-**Bug fix**
-* Fixed the production of mono from stereo. The bug was that mono was being produced by adding left and right (and not dividing by two), clamping the result if necessary, resulting in a signal that was twice as loud as it should have been and needlessly introducing the likelyhood of clipping. The bug has been fixed, preserving all 17 bits of the mono signal when translating to 32 bits for later processing. Dithering is also automatically enabled when mono output is selected. Fixes #522, with thanks to [RobDeBagel](https://github.com/RobDeBagel).
-
-Version 3.1d14 -- Version 3.1d9
-====
-**New Features**
-* Shairport Sync has changed the way it deals with pauses and resumes, caused either by using the controls of the source program, e.g. iTunes, or caused by resynchronisations. Specifically, from now on, on resumption after a short pause or glitch, it does not reset the output volume of the hardware mixer. This is so that any changes made by external controls are not needlessly reset by occasional network outages.
-* A new advanced setting for the `alsa` stanza is added: `mute_using_playback_switch`. The default is `"yes"`, which means that hardware mute using a feature called a playback switch will be used where available. Set it to `"no"` to prevent the playback switch being used. The motivation for this is to avoid using the alsa function call: `snd_mixer_selem_set_playback_switch_all`, which is incorrectly implemented on certain soundcards, including the emulated card in VMWare Fusion 8.5.
-
-Version 3.1d8
-====
-**New Features**
-* A volume-changed program hook has been added – a program can now be run whenever the volume control is set or changed. Similar to the `run_this_before_play_begins` and `run_this_after_play_ends` program hooks, you can specify a command line in the `general` `run_this_when_volume_is_set` setting. The AirPlay volume is simply appended to the end of the command line – leave a space if you want it treated as an extra argument. AirPlay volume goes from 0.0 to -30.0 and -144.0 means "mute".
-* A FreeBSD installer and startup script is now available. Use the `./configure` option `--with-os=freebsd` to get the right compilation flags, and use the `./configure` option `--with-freebsd-installer` to have a startup script installed and to have a user, group and runtime directory created.
-* The standard linux System V and `systemd` installers have been enhanced to create the user and
-group `shairport-sync` if necessary.
-* The standard linux System V installer creates a special runtime directory at `/var/run/shairport-sync` owned by the user `shairport-sync` and used to store its PID file.
-
-**Improvements**
-* The FreeBSD installation based on the `sndio` back end works well.
-
-Version 3.1d7
-====
-**Improvements**
+* Fixed bugs in the `ao`, `pulseaudio` and `sndio` back ends. Basically they were expecting default sample rate and depth information, and were terminating whne they saw explicit rate and depth data.
-Synchronisation is now working reasonably well in the `sndio` back end. Further work is necessary, but it looks pretty solid and the workarounds are no longer needed.
-
-Version 3.1d6
-====
-**New Feature**
-
-An extensively enhanced and updated backend for `sndio` thanks to the work of [t6](https://github.com/t6).
-
-`sndio` is *"the software layer of the OpenBSD operating system that manages the use of sound cards and MIDI ports."* Additionally, `sndio` *"... pays special attention to synchronization mechanisms and reliability required by music applications"*.
-
-Using `sndio` brings the possibility of "native" synchronisation to \*BSD. In fact, it already works but with some workarounds. The synchronization may not be exact, but it doesn't overrun or underrun. More exploration necessary.
-
-**Bug fix**
-* Fixed an off-by-one bug which allowed one more port than specified in the `udp_port_range` setting. Thanks to [kingosticks](https://github.com/kingosticks) for the alert.
-* Various small bugfixes to the `sndio` backend.
-
-**Enhancements**
-* Fixed some warnings detected by `clang` on FreeBSD. One was potentially a significant error.
-
-Version 3.1s5
-====
-Generally, more extensive changes have been to make all relevant operations reentrant.
-
-Your stability reports would be welcome.
-
-**New Feature**
-* A new command line option **--logOutputLevel** that logs the output level whenever the volume is changed. It's meant to be useful if you have to to determine the right level to set in volume_max_db.
-
-**Bug fix**
-* Sometimes when you stop a play and quickly start another, a short piece of audio from the end of the old session will play before the new session starts. Fixed by improving the flush command and by ignoring the first few frames after a play starts.
-
-**Enhancements**
-* Better reporting when a pipe can't be written to or can't be opened.
-
-Version 3.1s4
+Version 3.0.1
====
-**Bug fix**
-* If Shairport Sync tried to change a mixer level and failed, it would terminate. Now it just logs a debug report.
-
-Version 3.1s3
-====
-More extensive changes have been made to improve stability by making some operations reentrant. The instabilities occur sometimes when interrupting a play session by another.
-
-Version 3.1s1 and 3.1s2
-====
-**Bug fix**
-* 3.1s2 fixes issues with audio backend latency offset calculations.
-
-Other minor fixes will be detailed later.
-
-Version 3.1d1
-====
-This is a stability update. Some users have reported occasional crashes particularly when a play session ends and another begins immediately. The thread that plays a session was not reentrant, and this _may_ have been causing those stability problems. The player thread is now fully re-entrant, so those stability problems should be gone. The changes made were quite extensive, so more bugs may have been reintroduced.
-
-Please note that there are still problems with SoundCloud. Soundcloud seems to have problems with AirPlay in general -- the problems are not specific to Shairport Sync.
-
+This update fixes one alarming and potentially very noisy bug and restores the identification of Shairport Sync as "ShairportSync" so that TuneBlade recognises it as an open source application.
**Bug Fixes**
* Fixed a bug that was causing Shairport Sync to possibly make a very loud and alarming noise whenever an audio frame was missing.
-* In 2.8.6, a change was made to the way Shairport Sync identified itself, so that it could be recognised by TuneBlade as an open source application and treated preferentially. That change was inadvertently lost in the transition from 2.8.6 to 3.0. Now it's restored.
-
-
-Version 3.1d0
-====
-**New Features**
-* Two audio filters added – a volume-dependent-loudness and a convolution filter. Many thanks to [yannpom](https://github.com/yannpom) for this. for more information right now, please refer to the conversation at [#484](https://github.com/mikebrady/shairport-sync/pull/484).
-
-**Note**
-* Some housekeeping needs to be done on the location of configuration files and convolution impulse response files, and maybe compilation configuration settings, but they can wait for a little while.
-* Documentation isn't updated
+* In 2.8.6, a change was made to the way Shairport Sync identified itself, so that it could be recognised by TuneBlade as an open source application and treated preferentially. That change was inadventently lost in the transition from 2.8.6 to 3.0. Now it's restored.
Version 3.0
====
projects / thirdparty / shairport-sync.git / commitdiff
