shairport-sync-2.8.6/000077500000000000000000000000001301111713200145025ustar00rootroot00000000000000shairport-sync-2.8.6/.gitignore000066400000000000000000000005121301111713200164700ustar00rootroot00000000000000/INSTALL /shairport-sync /shairport-sync.exe /*.o /*~ *.xml~ /config.mk /config.h Makefile Makefile.in aclocal.m4 autom4te.cache compile config.* configure depcomp install-sh missing stamp-h1 .deps man/Makefile man/Makefile.in scripts/shairport-sync.service scripts/shairport-sync # Some eclipse project files .cproject .project shairport-sync-2.8.6/.travis.yml000066400000000000000000000052461301111713200166220ustar00rootroot00000000000000language: c sudo: required dist: trusty env: matrix: - CFG="--with-alsa --with-avahi --with-ssl=openssl --with-soxr --with-metadata --with-systemv" - CFG="--with-alsa --with-avahi --with-ssl=polarssl --with-soxr --with-metadata --with-systemv" - CFG="--with-alsa --with-avahi --with-ssl=openssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-avahi --with-ssl=polarssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-avahi --with-ssl=polarssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-avahi --with-ssl=openssl --with-soxr --with-metadata --with-systemd" - CFG="--with-stdio --with-avahi --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-stdio --with-avahi --with-ssl=polarssl --with-metadata --with-systemd" - CFG="--with-pipe --with-avahi --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-pipe --with-avahi --with-ssl=polarssl --with-metadata --with-systemd" - CFG="--with-ao --with-avahi --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-ao --with-avahi --with-ssl=polarssl --with-metadata --with-systemd" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=openssl --with-soxr --with-metadata --with-systemv" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=polarssl --with-soxr --with-metadata --with-systemv" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=openssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=polarssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=polarssl --with-soxr --with-metadata --with-systemd" - CFG="--with-alsa --with-tinysvcmdns --with-ssl=openssl --with-soxr --with-metadata --with-systemd" - CFG="--with-stdio --with-tinysvcmdns --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-stdio --with-tinysvcmdns --with-ssl=polarssl --with-metadata --with-systemd" - CFG="--with-pipe --with-tinysvcmdns --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-pipe --with-tinysvcmdns --with-ssl=polarssl --with-metadata --with-systemd" - CFG="--with-ao --with-tinysvcmdns --with-ssl=openssl --with-metadata --with-systemd" - CFG="--with-ao --with-tinysvcmdns --with-ssl=polarssl --with-metadata --with-systemd" script: - autoreconf -fi - ./configure $CFG - make before_install: - sudo apt-get -qq update - sudo apt-get install -y libdaemon-dev avahi-daemon libavahi-client-dev addons: apt: packages: - libasound2-dev - libsoxr-dev - libpopt-dev - libssl-dev - libpolarssl-dev - libconfig-dev - xmltoman - libao-dev shairport-sync-2.8.6/AUTHORS000066400000000000000000000000001301111713200155400ustar00rootroot00000000000000shairport-sync-2.8.6/COPYING000066400000000000000000000000721301111713200155340ustar00rootroot00000000000000Please refer to the individual source files for licenses. shairport-sync-2.8.6/CYGWIN.md000066400000000000000000000031431301111713200160250ustar00rootroot00000000000000Installing to Cygwin ---- This is based on installing onto a fresh default installation of Cygwin 2.4.1 (64-bit installation) running in Windows 10 inside VMWare Fusion on a Mac. Note: to enable Cygwin to resolve domain names, it was found necessary to go to Windows `Control Panel` > `Network and Internet` > `Network Connections` > `Ethernet0` > `Properties` > `Internet Protocol Version 4 (TCP/IPv4)` > `Properties`, select `Use the following DNS server addresses` and enter valid DNS server addresses, e.g. `8.8.8.8`. * Use `Cygwin Setup` to install the following packages: * `pkg-config` * `autoconf` * `automake` * `clang` * `libdaemon-devel` * `popt-devel` * `make` * `libao-devel` * `openssl-devel` * `libtool` * `git` * `wget` for convenience, * `flex` for compiling `libconfig` * `bison` for compiling `libconfig` * Download, configure, compile and install `libconfig`. For this, if your home directory name has a space in it, which happens by default with Cygwin, you should temporarily rename it to a single word, e.g. `Mike Brady` -> `mike`. This is to allow the `make install` script to work properly. ``` $ wget http://www.hyperrealm.com/libconfig/libconfig-1.5.tar.gz $ tar -xvzf libconfig-1.5.tar.gz $ cd libconfig-1.5 $ ./configure $ make $ make install ``` * Next, download, configure and compile Shairport Sync: ``` $ git clone https://github.com/mikebrady/shairport-sync.git $ cd shairport-sync $ autoreconf -fi $ PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --with-ao --with-ssl=openssl $ make ``` * That's it. There should be a `shairport-sync.exe` file in your directory. shairport-sync-2.8.6/ChangeLog000066400000000000000000000000001301111713200162420ustar00rootroot00000000000000shairport-sync-2.8.6/FEDORA.md000066400000000000000000000023221301111713200157630ustar00rootroot00000000000000Fedora Installation Guide ----- Install the toolchain and pre-requisites, if necessary: ``` % sudo yum install make automake gcc gcc-c++ kernel-devel % sudo yum install alsa-lib-devel autoconf automake avahi-devel libconfig-devel libdaemon-devel openssl-devel popt-devel soxr-devel ``` Download the tarball from the "releases" tab on github or use `wget` and then use `rpmbuild`. This example is for version 2.6: ``` % wget -O shairport-sync-2.6.tar.gz https://github.com/mikebrady/shairport-sync/archive/2.6.tar.gz % rpmbuild -ta shairport-sync-2.6.tar.gz ``` The `-ta` means "build all from this tarball". The RPM will be built in a directory and will have a pathname like, for example, `~/rpmbuild/RPMS/i686/shairport-sync-2.6-1.fc22.i686.rpm` You should then install it with (for this example): ``` %sudo rpm -i ~/rpmbuild/RPMS/i686/shairport-sync-2.6-1.fc22.i686.rpm ``` You may have to manually create the directory `/var/shairport-sync` for the installation to succeed. Having edited the configuration file `/etc/shairport-sync.conf` as appropriate (see "Configuring Shairport Sync" below), enable and start the service with: ``` %sudo systemctl enable shairport-sync.service %sudo systemctl start shairport-sync.service ``` shairport-sync-2.8.6/INSTALL.md000066400000000000000000000001271301111713200161320ustar00rootroot00000000000000Installation Instructions == Please refer to README.md for installation instructions. shairport-sync-2.8.6/LIBSOXR.md000066400000000000000000000020431301111713200161450ustar00rootroot00000000000000 The Raspbian image at the time of writing is the `May 2016` version, with the release date of `2016-05-10`. It does not include `libsoxr`, but it is available as a package via `apt-get`. Alternatively, `libsoxr` is very easy to compile. Here are very brief instructions to download, compile and install it: * Install `cmake`. This is used in the building of libsoxr: ``` sudo apt-get install cmake ``` * Download the `libsoxr source`: ``` git clone git://git.code.sf.net/p/soxr/code libsoxr ``` * `cd` into the `libsoxr` directory and start the build process: ``` cd libsoxr ./go ``` Be patient! This takes a long time on a Raspberry Pi -- it looks like it gets stuck around 40% or 50%, but it will finish if you let it. Having compiled `libsoxr`, it must now must be installed: ``` cd Release sudo make install ``` Finally, for Shairport Sync to be able to locate `libsoxr-dev` during compilation, you need to tell `ld` to catalogue it: ``` sudo ldconfig -v ``` That's it. Now you can select the `--with-soxr` option when you're building Shairport Sync. shairport-sync-2.8.6/LICENSES000066400000000000000000000025021301111713200156310ustar00rootroot00000000000000alac.c: Copyright (c) 2005, David Hammerton All rights reserved. see alac.c for full license text tinysvcmdns.c, tinysvcmdns.h: Copyright (C) 2011 Darell Tan All rights reserved. see tinysvcmdns.[ch] for full license text Shairport: Copyright (c) 2011-2013 James Laird Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. shairport-sync-2.8.6/Makefile.am000066400000000000000000000032441301111713200165410ustar00rootroot00000000000000SUBDIRS = man bin_PROGRAMS = shairport-sync shairport_sync_SOURCES = shairport.c rtsp.c mdns.c mdns_external.c common.c rtp.c player.c alac.c audio.c AM_CFLAGS = -Wno-multichar -DSYSCONFDIR=\"$(sysconfdir)\" if USE_CUSTOMPIDDIR AM_CFLAGS+= \ -DPIDDIR=\"$(CUSTOM_PID_DIR)\" endif if USE_AVAHI shairport_sync_SOURCES += mdns_avahi.c endif if USE_TINYSVCMDNS shairport_sync_SOURCES += mdns_tinysvcmdns.c tinysvcmdns.c endif if USE_ALSA shairport_sync_SOURCES += audio_alsa.c endif if USE_SNDIO shairport_sync_SOURCES += audio_sndio.c endif if USE_STDOUT shairport_sync_SOURCES += audio_stdout.c endif if USE_PIPE shairport_sync_SOURCES += audio_pipe.c endif if USE_DUMMY shairport_sync_SOURCES += audio_dummy.c endif if USE_AO shairport_sync_SOURCES += audio_ao.c endif if USE_PULSE shairport_sync_SOURCES += audio_pulse.c endif if USE_DNS_SD shairport_sync_SOURCES += mdns_dns_sd.c endif install-exec-hook: if INSTALL_CONFIG_FILES [ -e $(DESTDIR)$(sysconfdir) ] || mkdir $(DESTDIR)$(sysconfdir) cp scripts/shairport-sync.conf $(DESTDIR)$(sysconfdir)/shairport-sync.conf.sample [ -f $(DESTDIR)$(sysconfdir)/shairport-sync.conf ] || cp scripts/shairport-sync.conf $(DESTDIR)$(sysconfdir)/shairport-sync.conf endif if INSTALL_SYSTEMV [ -e $(DESTDIR)$(sysconfdir)/init.d ] || mkdir -p $(DESTDIR)$(sysconfdir)/init.d [ -f $(DESTDIR)$(sysconfdir)/init.d/shairport-sync ] || cp scripts/shairport-sync $(DESTDIR)$(sysconfdir)/init.d/ endif if INSTALL_SYSTEMD [ -e $(DESTDIR)$(systemdsystemunitdir) ] || mkdir -p $(DESTDIR)$(systemdsystemunitdir) [ -f $(DESTDIR)$(systemdsystemunitdir)/shairport-sync.service ] || cp scripts/shairport-sync.service $(DESTDIR)$(systemdsystemunitdir) endif shairport-sync-2.8.6/NEWS000066400000000000000000000000701301111713200151760ustar00rootroot00000000000000Please refer to RELEASENOTES.md and README.md for news. shairport-sync-2.8.6/README000066400000000000000000000000001301111713200153500ustar00rootroot00000000000000shairport-sync-2.8.6/README.md000066400000000000000000000773151301111713200157760ustar00rootroot00000000000000Shairport Sync ============= 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. 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!** 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). The latency to be used is specified by the source when it negotiates with Shairport Sync. Most sources set a latency of 88,200 frames — exactly two seconds. Recent versions of iTunes and forkedDaapd use a latency of 99,577 frames. Timestamps are measured relative to the source computer's clock – the `source clock`, but timing must be done relative to the clock of the computer running Shairport Sync – the `local clock`. This is done by synchronising the two clocks, usually to within a fraction of a millisecond, using a variant of NTP synchronisation protocols. To maintain the exact latency required, if an output device is running slow relative to the source, Shairport Sync will delete frames of audio to allow the device to keep up. If the output device is running fast, Shairport Sync will insert frames to keep time. The number of frames inserted or deleted is so small as to be almost inaudible on normal audio material. Frames are inserted or deleted as necessary at pseudorandom intervals. Alternatively, with `libsoxr` support, Shairport Sync can resample the audio feed to ensure the output device can keep up. This is less obtrusive than insertion and deletion but requires a good deal of processing power — most embedded devices probably can't support it. The process of insertion/deletion or resampling is rather inelegantly called “stuffing”. Shairport Sync is a substantial rewrite of the fantastic work done in Shairport 1.0 by James Laird and others — please see https://github.com/abrasive/shairport/blob/master/README.md#contributors-to-version-1x for a list of the contributors to Shairport 1.x and Shairport 0.x. From a "heritage" point of view, Shairport Sync is a fork of Shairport 1.0. Shairport Sync is mainly designed for `alsa` and thus for Linux, although since `alsa` has been ported to FreeBSD, Shairport Sync runs in FreeBSD too. It must have direct access to the output device, which must be a real sound card capable of working with 44,100 samples per second interleaved PCM stereo (you'll get a message in the logfile if there's a problem). For more about the motivation behind Shairport Sync, please see the wiki at https://github.com/mikebrady/shairport-sync/wiki. What else? -------------- * Better Volume Control — Shairport Sync offers finer control at very top and very bottom of the volume range. See http://tangentsoft.net/audio/atten.html for a good discussion of audio "attenuators", upon which volume control in Shairport Sync is modelled. See also the diagram of the volume transfer function in the documents folder. In addition, Shairport Sync can offer an extended volume control range on devices with a restricted range. * Hardware Mute — Shairport Sync will mute properly if the hardware supports it. * Fast Response — With hardware volume control, response is instantaneous; otherwise the response time is 0.15 seconds. * Non-Interruptible — Shairport Sync sends back a "busy" signal if it's already playing audio from another source, so other sources can't disrupt an existing Shairport Sync session. (If a source disappears without warning, the session automatically terminates after two minutes and the device becomes available again.) * Metadata — Shairport Sync can deliver metadata supplied by the source, such as Album Name, Artist Name, Cover Art, etc. through a pipe to a recipient application program — see https://github.com/mikebrady/shairport-sync-metadata-reader for a sample recipient. Sources that supply metadata include iTunes and the Music app in iOS. * Raw Audio — Shairport Sync can deliver raw PCM audio to standard output or to a pipe. This output is delivered synchronously with the source after the appropriate latency and is not interpolated or "stuffed" on its way through Shairport Sync. * Autotools and Libtool Support — the Shairport Sync build process uses GNU `autotools` and `libtool` to examine and configure the build environment — important for portability and for cross compilation. Previous versions of Shairport looked at the current system to determine which packages were available, instead of looking at the target system for what packages were available. Status ------ Shairport Sync works on a wide variety of Linux devices. It works on standard Ubuntu laptops, on the Raspberry Pi with Raspbian Wheezy and Jessie, Arch Linux and OpenWrt, and it runs on a Linksys NSLU2 and a TP-Link 710N using OpenWrt. It works with built-in audio and with a variety of USB-connected audio amplifiers and DACs, including a cheapo USB "3D Sound" dongle, a first generation iMic and a Topping TP30 amplifier with a USB DAC input. It will not work properly — if at all — with a PulseAudio (pseudo-)output device. Using a port of the `alsa` system, Shairport Sync runs rather well on FreeBSD. Shairport Sync runs well on the Raspberry Pi. It can drive the built-in sound card, though the audio out of the card is of poor quality (see the note below on configuring the Raspberry Pi to make best use of it). USB-connected sound cards work well, though [very] old versions of Raspbian appear to suffer from a problem — see http://www.raspberrypi.org/forums/viewtopic.php?t=23544, so it is wise to update. Shairport Sync works well with the IQAudIO Pi-DAC — see http://www.iqaudio.com. At the time of writing, OpenWrt trunk does not support USB audio well on the Raspberry Pi. Shairport Sync runs on Ubuntu, OpenWrt, Debian, Arch Linux and Fedora inside VMWare Fusion on a Mac, but synchronisation in inaccurate — possibly because the soundcard is being emulated. Shairport Sync will output to `alsa` cards, to standard output and to pipes using appropriate backends. You can try compiling additional backends in as you wish, but it definitely will not work properly with them. Maybe someday... 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 --------------------- 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`. **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/. 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). **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. **Fedora:** Please see the guide at [FEDORA.md](https://github.com/mikebrady/shairport-sync/blob/master/FEDORA.md). **Cygwin:** Please see the guide at [CYGWIN.md](https://github.com/mikebrady/shairport-sync/blob/master/CYGWIN.md). Sincere thanks to all package contributors! **General Build Instructions** To build Shairport Sync from sources on Debian, Ubuntu, Raspbian, etc. follow these instructions. The following libraries are required: * OpenSSL or PolarSSL * Avahi * ALSA * libdaemon * autoconf * automake * libtool * libpopt * libconfig Optional: * libsoxr Many Linux distributions have Avahi and OpenSSL already in place, so normally it probably makes sense to choose those options rather than tinysvcmdns or PolarSSL. Libsoxr is available in recent Linux distributions, but it requires lots of processor power — chances are an embedded processor won't be able to keep up. Debian, Ubuntu and Raspbian users can get the basics with: - `apt-get install build-essential git` – these may already be installed. - `apt-get install autoconf automake libtool libdaemon-dev libasound2-dev libpopt-dev libconfig-dev` - `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 PolarSSL otherwise. - `apt-get install libpolarssl-dev` if you want to use PolarSSL, or use OpenSSL/libcrypto otherwise. - `apt-get install libsoxr-dev` if you want support for libsoxr-based resampling. This library is in many recent distributions, including Jessie and Raspioan Jessie; if not, instructions for how to build it from source for Raspian/Debian Wheezy are available at [LIBSOXR.md](https://github.com/mikebrady/shairport-sync/blob/master/LIBSOXR.md). **Download Shairport Sync:** `$ git clone https://github.com/mikebrady/shairport-sync.git` Next, `cd` into the shairport-sync directory and execute the following command: ``` $ autoreconf -i -f ``` (Note that the `autoreconf...` step may take some time on less powerful machines.) **Choose the appropriate `--with-*` options:** - `--with-alsa` for the ALSA audio back end. This is required. - `--with-stdout` include an optional backend module to enable raw audio to be output through standard output (stdout). - `--with-pipe` include an optional backend module to enable raw audio to be output through a unix pipe. - `--with-avahi` or `--with-tinysvcmdns` for mdns support. Avahi is a widely-used system-wide zero-configuration networking (zeroconf) service — it may already be in your system. If you don't have Avahi, or similar, then consider including tinysvcmdns, which is a tiny zeroconf service embedded inside the shairport-sync application itself. To enable multicast for `tinysvcmdns`, you may have to add a default route with the following command: `route add -net 224.0.0.0 netmask 224.0.0.0 eth0` (substitute the correct network port for `eth0`). You should not have more than one zeroconf service on the same system — bad things may happen, according to RFC 6762, §15. - `--with-ssl=openssl` or `--with-ssl=polarssl` for encryption and related utilities using either OpenSSL or PolarSSL. - `--with-soxr` for libsoxr-based resampling. - `--with-piddir` for specifying where the PID file should be stored. This directory is normally chosen automatically. The directory must be writable. If you use this option, you may have to edit the init script to search for the PID file in your new location. - `--with-metadata` to add support for Shairport Sync to pipe metadata to a compatible application of your choice. See https://github.com/mikebrady/shairport-sync-metadata-reader for a sample metadata reader. - `--with-systemv` to install a System V init script at the `make install` stage. Default is not to to install. - `--with-systemd` to install a systemd service description at the `make install` stage. Default is not to to install. - `--with-configfile` to install a configuration file and a separate sample file at the `make install` stage. Default is to install. An existing `/etc/shairport-sync.conf` will not be overwritten. - `--with-pkg-config` to use pkg-config to find libraries. Default is to use pkg-config — this option is for special purpose use. **Determine if it's a `systemd` or a "System V" installation:** At the time of writing, there are two widely-used systems for starting programs automatically at startup: `systemd` and "System V" . (There are others, but they are not considered here.) To see if the `systemd` process is running on your system, enter the following command: `$ ps aux | grep systemd | grep -v grep` On a system using `systemd` (this is from a Raspberry Pi running Raspbian Jessie) you'll get many lines containing `systemd`, for example: ``` pi@raspberrypi ~ $ ps aux | grep systemd | grep -v grep root 90 0.1 0.6 8088 2764 ? Ss 08:00 0:01 /lib/systemd/systemd-journald root 93 0.0 0.6 11816 3004 ? Ss 08:00 0:00 /lib/systemd/systemd-udevd root 502 0.0 0.5 3824 2436 ? Ss 08:00 0:00 /lib/systemd/systemd-logind message+ 528 0.0 0.7 5568 3172 ? Ss 08:00 0:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation pi 983 0.0 0.7 4912 3256 ? Ss 08:00 0:00 /lib/systemd/systemd --user pi@raspberrypi ~ $ ``` whereas on a system without `systemd` – presumably using System V – (this is a from a Raspberry Pi running Raspbian Wheezy) , you'll get nothing: ``` pi@raspberrypi ~ $ ps aux | grep systemd | grep -v grep pi@raspberrypi ~ $ ``` Choose `--with-systemd` or `--with-systemv` on the basis of the outcome. **Choose the location of the configuration file** A final consideration is the location of the configuration file `shairport-sync.conf`. This will be placed in the directory specified by the `sysconfdir` configuration variable, which defaults to `/usr/local/etc`. This is normal in BSD Unixes, but is unusual in Linux. Hence, for Linux installations, you need to set the `sysconfdir` variable to `/etc` using the configuration setting `--sysconfdir=/etc`. **Sample `./configure` command with parameters for a typical Linux `systemd` installation:** Here is an example, suitable for Linux installations that use `systemd`, such as Ubuntu 16.04 and Raspbian Jessie: `$ ./configure --sysconfdir=/etc --with-alsa --with-avahi --with-ssl=openssl --with-metadata --with-soxr --with-systemd` * Omit the `--with-soxr` if the libsoxr library is not available. * For installation into a System V system, replace the `--with-systemd` with `--with-systemv`. **Build the application:** Enter: `$ make` to build the application. **Install into to a `systemd` system** To complete the installation, you need to define a `shairport-sync` group and user. This is a security measure – the user and group are relatively unprivileged, and the user does not have login priviliges. The user must be a member of the `audio` group to be able to access the audio hardware. The following commands define the group and user correctly if they do not already exist (note the use of `sudo` – omit this if you already have superuser privileges: ``` $ getent group shairport-sync &>/dev/null || sudo groupadd -r shairport-sync >/dev/null $ getent passwd shairport-sync &> /dev/null || sudo useradd -r -M -g shairport-sync -s /usr/bin/nologin -G audio shairport-sync >/dev/null ``` Next, enter: ``` $ sudo make install ``` to install `shairport-sync` along with a `man` page, a default configuration file and a `systemd` configuration file called `shairport-sync.service` to launch it automatically at system startup. To enable Shairport Sync to start automatically at system startup, enter: `$ sudo systemctl enable shairport-sync` **Install into a System V system** If you are installing onto a System V system: ``` $ sudo make install ``` to install `shairport-sync` along with a `man` page, a default configuration file and a System V startup script to launch it automatically at system startup. To complete the installation, enter: ``` $ sudo update-rc.d shairport-sync defaults 90 10 ``` **Man Page** You can view the man page here: http://htmlpreview.github.io/?https://github.com/mikebrady/shairport-sync/blob/master/man/shairport-sync.html Configuring Shairport Sync -------- There are two logically distinct parts to getting Shairport Sync to run properly on your machine — (1) starting and stopping it and (2) ensuring it has the right settings. **(1) Starting and Stopping:** Starting and stopping Shairport Sync automatically is taken care of differently in different versions of Linux – see the previous section for an example of installing into a `systemd` or a System V based system. **(2) Settings:** To get the best from Shairport Sync, you’ll need to (a) give Shairport Sync a service name by which it will be seen in iTunes etc., (b) specify the output device to use and (c) specify the name of the mixer volume control to use to control the output level. To get values for (b) and (c) you might need to explore the ALSA output devices with a program like `alsamixer` or similar. Shairport Sync reads settings from a configuration file at `/etc/shairport-sync.conf`. When you run `$sudo make install`, a sample configuration file is installed (or updated) at `/etc/shairport-sync.conf.sample`. This contains all the setting groups and all the settings available, but they all are commented out (comments begin with `//`) so that default values are used. The file contains explanations of the settings, useful hints and suggestions. In addition, if the file doesn't already exist, a default configuration is installed at `/etc/shairport-sync.conf`, which should work in almost any system with a sound card. Settings in the configuration file are grouped. For instance, there is a `general` group within which you can use the `name` tag to set the service name. Suppose you wanted to set the name of the service to `Front Room`, give the service the password `secret` and used `libsoxr` interpolation, then you should do the following: ``` general = { name = "Front Room"; password = "secret"; interpolation = "soxr"; // ... other general settings }; ``` (Remember, anything preceded by `//` is a comment and will have no effect on the setting of Shairport Sync.) The `alsa` group is used to specify properties of the output device. The most obvious setting is the name of the output device which you can set using the `output_device` tag. The following `alsa` group settings are very important for maximum performance. If your audio device has a mixer that can be use to control the volume, then Shairport Sync can use it to give instant response to volume and mute commands and it can offload some work from the processor. * The `mixer_control_name` tag allows you to specify the name of the mixer volume control. * The `mixer_device` tag allows you specify where the mixer is. By default, the mixer is on the `output_device`, so you only need to use the `mixer_device` tag if the mixer is elsewhere. This can happen if you specify a *device* rather than a *card* with the `output_device` tag, because normally a mixer is associated with a *card* rather than a device. Suppose you wish to use the output device `5` of card `hw:0` and the mixer volume-control named `PCM`: ``` alsa = { output_device = "hw:0,5"; mixer_device = "hw:0"; mixer_control_name = "PCM"; // ... other alsa settings }; ``` 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`. This is to facilitate situations where something has to be done before and after playing, e.g. switching on an amplifier beforehand and switching it off afterwards. Set the `wait_for_completion` value to `"yes"` for Shairport Sync to wait until the respective commands have been completed before continuing. Please note that the full path to the programs must be specified, and script files will not be executed unless they are marked as executable and have the standard `#!/bin/...` first line. (This behaviour may be different from other Shairports.) Note: Shairport Sync can take configuration settings from command line options. This is mainly for backward compatability, but sometimes still useful. For normal use, it is strongly recommended that you use the configuration file method. **Raspberry Pi** The Raspberry Pi has a built-in audio DAC that is connected to the device's headphone jack. This provides a low-quality output that is nevertheless useful for testing purposes and may be adequate for [very] casual listening. It is not HiFi -- it is quite noisy and can't play anything above about 15kHz. A further problem is that it declares itself to have a very large mixer volume control range -- all the way from -102.38dB up to +4dB, a range of 106.38 dB. In reality, only the top 30dB of it is in any way usable. To help get the most from the DAC, consider using the `volume_range_db` setting in the `general` stanza to instruct Shairport Sync to use the top of the DAC mixer's declared range. For example, if you set the `volume_range_db` figure to 30, the top 30 dB of the range will the used. With this setting on the Raspberry Pi, maximum volume will be +4dB and minimum volume will be -26dB, below which muting will occur. From a user's point of view, the effect of using this setting is to move the minimum usable volume all the way down to the bottom of the user's volume control, rather than have the minimum usable volume concentrated very close to the maximum volume. Another setting to consider is the `general` `drift` setting: you should set it to a larger number, such as 352, to reduce the amount of overcorrection that seems to occur when using the Raspberry Pi's built-in DAC. *Command Line Arguments* As previously mentioned, you can use command line arguments to provide settings to Shairport Sync as before, though newer settings will only be available via the configuration file. For full information, please read the Shairport Sync `man` page, also available at http://htmlpreview.github.io/?https://github.com/mikebrady/shairport-sync/blob/master/man/shairport-sync.html. Apart from the following options, all command line options can be replaced by settings in the configuration file. Here is a brief description of command line options that are not replicated by settings in the settings file. * The `-c` option allows you to specify the location of the configuration file — default is `/etc/shairport-sync.conf`. * The `-V` option gives you version information about Shairport Sync and then quits. * The `-d` option causes Shairport Sync to properly daemonise itself, that is, to run in the background. You may need sudo privileges for this. * The `-k` option causes Shairport Sync to kill an existing Shairport Sync daemon. You may need to have sudo privileges for this. The System V init script at `/etc/init.d/shairport-sync` has a bare minimum : `-d`. Basically all it does is put the program in daemon mode. The program will read its settings from the configuration file, normally `/etc/shairport-sync.conf`. Examples -------- Here are some examples of complete configuration files. ``` general = { name = "Joe's Stereo"; }; alsa = { output_device = "hw:0"; }; ``` This gives the service a particular name — "Joe's Stereo" and specifies that audio device hw:0 be used. For best results — including getting true mute and instant response to volume control and pause commands — you should access the hardware volume controls. Use `amixer` or `alsamixer` or similar to discover the name of the mixer control to be used as the `mixer_control_name`. Here is an example for for a Raspberry Pi using its internal soundcard — device hw:0 — that drives the headphone jack: ``` general = { name = "Mike's Boombox"; }; alsa = { output_device = "hw:0"; mixer_control_name = "PCM"; }; ``` Here is an example of using soxr-based resampling and driving a Topping TP30 Digital Amplifier, which has an integrated USB DAC and which is connected as audio device `hw:1`: ``` general = { name = "Kitchen"; interpolation = "soxr"; }; alsa = { output_device = "hw:1"; mixer_control_name = "PCM"; }; ``` For a cheapo "3D Sound" USB card (Stereo output and input only) on a Raspberry Pi: ``` general = { name = "Front Room"; }; alsa = { output_device = "hw:1"; mixer_control_name = "Speaker"; }; ``` For a first generation Griffin iMic on a Raspberry Pi: ``` general = { name = "Attic"; }; alsa = { output_device = "hw:1"; mixer_control_name = "PCM"; }; ``` For an NSLU2, which has no internal soundcard, there appears to be a bug in ALSA — you can not specify a device other than "default". Thus: On an NSLU2, to drive a first generation Griffin iMic: ``` general = { name = "Den"; }; alsa = { mixer_control_name = "PCM"; }; ``` On an NSLU2, to drive the "3D Sound" USB card: ``` general = { name = "TV Room"; }; alsa = { mixer_control_name = "Speaker"; }; ``` Latency ------- Latency is the exact time from a sound signal's original timestamp until that signal actually "appears" on the output of the audio output device, usually a Digital to Audio Converter (DAC), irrespective of any internal delays, processing times, etc. in the computer. Shairport Sync uses latencies supplied by the source, typically either 88,200 or 99,577 frames. You shouldn't need to change them. (The `latencies` stanza in the configuration file and the various latency command-line options are now obselete and are deprecated.) Problems can arise when you are trying to synchronise with speaker systems — typically surround-sound home theatre systems — that have their own inherent delays. You can compensate for an inherent delay using the appropriate backend (typically `alsa`) `audio_backend_latency_offset`. Set this offset (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. Resynchronisation ------------- Shairport Sync actively maintains synchronisation with the source. If synchronisation is lost — say due to a busy source or a congested network — Shairport Sync will mute its output and resynchronise. The loss-of-sync threshold is a very conservative 50 ms — i.e. the actual time and the expected time must differ by more than 50 ms to trigger a resynchronisation. Smaller disparities are corrected by insertions or deletions, as described above. * You can vary the resync threshold, or turn resync off completely, with the `general` `resync_threshold` setting. Tolerance --------- Playback synchronisation is allowed to wander — to "drift" — a small amount before attempting to correct it. The default is 88 frames, i.e. 2 ms. The smaller the tolerance, the more likely it is that overcorrection will occur. Overcorrection is when more corrections (insertions and deletions) are made than are strictly necessary to keep the stream in sync. Use the `statistics` setting to monitor correction levels. Corrections should not greatly exceed net corrections. * You can vary the tolerance with the `general` `drift` setting. Some Statistics --------------- If you turn on the `general` `statistics` setting, statistics like this will be printed at intervals on the console (or in the logfile if running in daemon mode): `Sync error: -35.4 (frames); net correction: 24.2 (ppm); corrections: 24.2 (ppm); missing packets 0; late packets 5; too late packets 0; resend requests 6; min DAC queue size 4430.` "Sync error" is the average deviation from exact synchronisation. The example above indicates that the output is on average 35.4 frames ahead of exact synchronisation. Sync is allowed to drift by the `general` `drift` setting — 88 frames (± 2 milliseconds) by default — before a correction will be made. "Net correction" is actually the net sum of corrections — the number of frame insertions less the number of frame deletions — given as a moving average in parts per million. After an initial settling period, it represents the drift — the divergence between the rate at which frames are generated at the source and the rate at which the output device consumes them. The example above indicates that the output device is consuming frames 24.2 ppm faster than the source is generating them. "Corrections" is the number of frame insertions plus the number of frame deletions (i.e. the total number of corrections), given as a moving average in parts per million. The closer this is to the net corrections, the fewer "unnecessary" corrections that are being made. Third party programs tend to have much larger levels of corrections. For reference, a drift of one second per day is approximately 11.57 ppm. Left uncorrected, even a drift this small between two audio outputs will be audible after a short time. The above sample is from a second-generation iPod driving the Raspberry Pi which is connected over Ethernet. It's not unusual to have resend requests, late packets and even missing packets if some part of the connection to the Shairport Sync device is over WiFi. Late packets can sometimes be asked for and received multiple times. Sometimes late packets are sent and arrive too late, but have already been sent and received in time, so weren't needed anyway... "Min DAC queue size" is the minimum size the queue of samples in the output device's hardware buffer was measured at. It is meant to stand at 0.15 seconds = 6,615 samples, and will go low if the processor is very busy. If it goes below about 2,000 then it's a sign that the processor can't really keep up. Troubleshooting --------------- Please refer to [TROUBLESHOOTING](https://github.com/mikebrady/shairport-sync/blob/master/TROUBLESHOOTING.md) for a few hints, contributed by users. shairport-sync-2.8.6/RELEASENOTES.md000066400000000000000000001703671301111713200167330ustar00rootroot00000000000000Version 2.8.6 – Stable Candidate ---- **Enhancements** * This release contains a small change – it identifies itself as a ShairportSync device rather than an AirPort device. This should make it possible for Tuneblade, and possibly other players, to recognise it correctly. Version 2.8.5 – Stable Version ---- This release includes bug fixes and minor enhancements and is recommended for all users. Note: if you're upgrading, there is a new `./configure` option: ==== The build process now uses the directory path `sysconfdir` to determine where to place the configuration file `shairport-sync.conf`. The default value for `sysconfdir` is `/usr/local/etc` which is used in the BSD family, whereas `/etc` is normally used in Linux. To retain the present behaviour of Shairport Sync, *you must add an extra parameter to the `./configure... ` command.* The parameter you must add is `--sysconfdir=/etc`. (This has been added to the sample configuration command line in README.md.) The enhancements and bug fixes in 2.8.5 were made in versions 2.8.4.1 to 2.8.4.8 inclusive. Please read below for the full list. For advice on updating an installation you built yourself, please visit the [UPDATING](https://github.com/mikebrady/shairport-sync/blob/master/UPDATING.md) page. ======= Version 2.8.4.8 – Development Version ---- **Enhancements** * Add a new metadata item `clip` (for `CL`ient `IP`). This item is a string comprising the IP number of the "client", and is sent when a play session is starting. The "client" is the sender of the audio stream, e.g. iTunes on a Mac, or the Music player in iOS. * When synchronisation has been disabled on the ALSA device (you should only do this for testing), Shairport Sync now refrains from asking for buffer length information from the device. Version 2.8.4.7 – Development Version ---- * This update means the build process now uses the directory path `sysconfdir` to determine where to place the configuration file `shairport-sync.conf`. The default value for `sysconfdir` is `/usr/local/etc` which is used in the BSD family, whereas `/etc` is normally used in Linux. So, to retain the present behaviour of Shairport Sync, you must add an extra parameter to the `./configure... ` command. The parameter you must add is `--sysconfdir=/etc`. (This has been added to the sample configuration command line in README.md.) * Shairport Sync has been updated to use the value of `sysconfdir` to determine where to look for the configuration file. If `sysconfdir` has been left with its default value of `/usr/local/etc`, then Shairport Sync will look for `/usr/local/etc/shairport-sync.conf`. If, as recommended for Linux, `sysconfdir` has been set to `/etc`, then Shairport Sync will look, as before, for `/etc/shairport-sync.conf`. **Enhancement** * The version string output when you use the command-line option `-V` now includes the value of the `sysconfdir`, e.g. `2.8.4.7-OpenSSL-Avahi-ALSA-soxr-sysconfdir:/etc`. Version 2.8.4.6 – Development Version ---- **Enhancement** * Add a new `alsa` configuration setting: `use_mmap_if_available` to control the use of mmap. The default is `"yes"` -- see [#351](https://github.com/mikebrady/shairport-sync/issues/351). Version 2.8.4.5 – Development Version ---- **Enhancement** * Handle varying packet lengths -- this makes it compatible with the HTC Connect, HTCs AirPlay implementation. Thanks to [Jörg Krause](https://github.com/joerg-krause) for his detective work, and see [#338](https://github.com/mikebrady/shairport-sync/issues/338). Version 2.8.4.4 – Development Version ---- **Enhancement** * Use alsa direct access (mmap) feature to improve performance if mmap is supported. Thanks to [Yihui Xiong](https://github.com/xiongyihui). Version 2.8.4.3 – Development Version ---- **Bug Fix** * Set the RTSP socket to close on `exec()` of child processes; otherwise, background `run_this_before_play_begins` or `run_this_after_play_ends` commands that are sleeping prevent the daemon from being restarted because the listening RTSP port is still in use. Fixes [#329](https://github.com/mikebrady/shairport-sync/issues/329). Version 2.8.4.2 – Development Version ---- **Bug Fixes** * Fixed an issue where you could not compile the audio_pipe back end without enabling metadata support (thanks to [busa-projects](https://github.com/busa-projects) for reporting the issue). * Fixed a few small issues causing compiler warnings in `mdns_dns_sd.c`. **Other** * Removed the INSTALL file – it's generated automatically by `autoreconf -fi` anyway – added it to the files to be ignored in `.gitignore` and added a simple `INSTALL.md` file. Version 2.8.4.1 – Development Version ---- **Bug Fixes** * Fixed two issues when including support for `pulseaudio`. * Corrected two small errors in sample parameters for the UDP metadata stream settings, thanks to [rkam](https://github.com/rkam). Version 2.8.4 – Stable Version ---- This release includes important bug fixes and minor enhancements and is recommended for all users. No settings need to be changed. For advice on updating an installation you built yourself, please visit the [UPDATING](https://github.com/mikebrady/shairport-sync/blob/master/UPDATING.md) page. The following is a summary of the bug fixes and enhancements since version 2.8.3. **Bug Fixes** * Checks have been added for empty or NULL audio buffers that were causing assertion violations and subsequent abnormal program termination. * An IPv6 bug has been fixed — a bug in the networking software would not allow an IPv6 link-local connection to be made from a client if Shairport Sync was running on a device with more than one network interface. The solution was to take account of the `config_id` information. * Some problems have been fixed with the non-blocking write function used to write metadata. * A bug in the volume control transfer function has been fixed, thanks to [Jörg Krause](https://github.com/joerg-krause). **Enhancements** * Shairport Sync now works with [AllConnect/Streambels](http://allconnectapp.com) on Android with password protection. (As with all Android clients, you should set the `drift` to something large, like 500 or 1,000, as the timekeeping of these clients isn't as accurate as that of iTunes, etc.) * The networking subsystem has been modified to always use the same IP number during a session. Background: the computer Shairport Sync is running on can have many IP numbers active at the same time – various IPv6 numbers and also various IPv4 numbers. During a play session, when Shairport Sync has to create connections back to the source, it would use an automatically-assigned IP number for itself, but that number might not be same as the the number used earlier in the session. From now on, it will always use the same IP number it used when the connection was first established. Thanks to [ejurgensen](https://github.com/ejurgensen) for help with this. * Experimental support has been added for a softvol plugin, thanks to the work of [Jörg Krause](https://github.com/joerg-krause) -- see [#293](https://github.com/mikebrady/shairport-sync/pull/293). * A `playback_mode` setting has been added to allow the selection of `stereo` (default) or `mono` playback -- thanks to [faceless2](https://github.com/faceless2). * The new default service name is now the device's `hostname`, with its first character capitalised (ASCII only). * Substitutions can now be made in the service name. The following substitutions can be used in the service name: `%h` for the `hostname`, `%H` for the `hostname` with the first letter capitalised, `%v` for the version number and `%V` for the full version string. Maximum length is 50 characters. * An existing `shairport-sync.service` file will not be overwritten by `sudo make install`. * The text strings advertising the capabilities of Shairport Sync over Bonjour/Zeroconf/Avahi have been changed and now more closely match those of an AirPort Express Base Station (First Generation). * It is now possible to set the amount of time to wait for the metadata pipe to become ready for writing. The setting is called `pipe_timeout` in the `metadata` section. Default is 5,000 milliseconds. * Metadata can now be provided via UDP -- thanks to [faceless2](https://github.com/faceless2). * Statistics output is more machine readable -- thanks to [Jörg Krause](https://github.com/joerg-krause) * The `shairport-sync.spec` file has been updated for compatability with building Debian packages using `checkinstall` -- thanks to [vru1](https://github.com/vru1). Version 2.8.3.11 – Development Version ---- **Bug Fix** Fixed some problems with the non-blocking write function used to write to the metadata pipe. **Enhancement** It is now possible to set the amount of time to wait for the metadata pipe to become ready for writing. The setting is called `pipe_timeout` in the `metadata` section. Default is 5,000 milliseconds. Version 2.8.3.10 – Development Version ---- **Bug Fix** * Restored metadata feed lost in 2.8.3.7. Version 2.8.3.9 – Development Version ---- **Enhancements** * Substitutions can now be made in the service name, i.e. the name that appears in iTunes, etc. The following substitutions can be used in the service name you specify: `%h` for the hostname, `%H` for the hostname with the first letter capitalised, `%v` for the version number and `%V` for the full version string. Maximum length is 50 characters. * The new default service name is simply the hostname, with its first character capitalised. * An existing `shairport-sync.service` file will not be overwritten by `sudo make install`. Version 2.8.3.7 – Development Version ---- **Enhancements** * Shairport Sync now works with AllConnect/Streambels on Android with password protection. (As with all Android clients, you should set the `drift` to something large, like 500 or 1,000, as the timekeeping of these clients isn't as accurate as that of iTunes, etc.) * The text strings advertising the capabilities of Shairport Sync over Bonjour/Zeroconf/Avahi have been changed and now more closely match those of an AirPort Express Base Station (First Generation). Version 2.8.3.6 – Development Version ---- **Bug fix** An IPv6 link-local connection issue was fixed. A bug in the networking software would not allow an IPv6 link-local connection to be made from a client if Shairport Sync was running on a device with more than one network interface. The solution was to take account of the `config_id` information. Version 2.8.3.5 – Development Version ---- **Enhancement** Experimental support for a softvol plugin, thanks to the work of [Jörg Krause](https://github.com/joerg-krause) -- see [#293](https://github.com/mikebrady/shairport-sync/pull/293). **Bug fix** Add checks for empty or NULL audio buffers that seem to be causing assertion violations and subsequent abnormal program termination. Version 2.8.3.4 – Development Version ---- **Bug Fix** The networking subsystem has been modified to always use the same IP number during a session. Background: the computer Shairport Sync is running on can have many IP numbers active at the same time – various IPv6 numbers and also various IPv4 numbers. During a play session, when Shairport Sync has to create connections back to the source, it would use an automatically-assigned IP number for itself, but that number might not be same as the the number used earlier in the session. From now on, it will always use the same IP number it used when the connection was first established. Thanks to [ejurgensen](https://github.com/ejurgensen) for help with this. Changed the `mono` setting for a `playback_mode` setting with two possible values: `stereo` (default) and `mono`. Version 2.8.3.3 – Deleted ---- Version 2.8.3.2 – Deleted ---- Version 2.8.3.1 – Development Version ---- Added a new `mono` setting -- thanks to [faceless2](https://github.com/faceless2). Documentation to follow. Version 2.8.3 – Stable Version ---- A bug in 2.8.2 caused Avahi to fail at startup under some circumstances with older installations. The problem was that sometimes the `regtype` setting would not be initialised properly. Version 2.8.2 – Stable Version ---- Version 2.8.2 is derived from development version 2.9.5.7 and has stability improvements, bug fixes and a few special-purpose enhancements. For full details, please refer to the release notes here, back as far as 2.8.1. Version 2.9.5.7 – Development Version ---- Version 2.9.5.7 contains general bug fixes and enhancements for some special situations. **Bug Fixes** * Getting delay and latency information from the `alsa` subsystem has been improved -- bugs fixed, error codes handled better, arithmetic handling (hopefully) better. * If latency information is temporarily unavailable from the `alsa` subsystem, skip trying to synchronise until the next time. * Some condition variables and a mutex were uninitialised, yikes! Fixed. * A bug that set the output volume to maximum at the same time as muting the output has been fixed. AFAIK, this was inaudible, but it was scary looking. * Recover from name collisions in Avahi. * Detect and handle empty buffers better. **Enhancements** * Turn off synchronisation. This is an advanced feature and generally leads to buffer underrun or overrun. * Set `alsa` buffer size and `alsa` period size. There are advanced features, mainly for debugging. They may be removed. * Change the Zeroconf/Bonjour `regtype` to enable Shairport Sync to continue to run but to be invisible to AirPlay clients. Special purpose usage only. * Output total number of packets and the play time of a session when statistics are enabled. Version 2.9.4 – Development Version ---- Version 2.9.4 corrects some bugs in how Avahi error conditions are handled. **Bug Fix** * During operation, if the network disappeared, Avahi would occasionally report an error. This would cause Shairport Sync to attempt to terminate gracefully (which is the wrong thing to do in the circumstances). However, the termination attempt was actually causing an assertion violation crash. These errors are now simply logged. Version 2.9.3 – Development Version ---- Version 2.9.3 is 2.8.1 with documentation and version changes to indicate that it's in the development branch. Version 2.8.1 – Stable Version ---- Version 2.8.1 is derived from development version 2.9.2 and has stability improvements and important bug fixes. For full details, please refer to the release notes here, back as far as 2.9.1. Version 2.9.2 – Development Version ---- Version 2.9.2 focusses on further bug fixes and stability improvements. * Enhanced stability: an important bug has been fixed in the handling of missing audio frames – i.e. what happens when a frame of audio is truly missing, after all attempts to fetch it have been unsuccessful. The bug would cause Shairport Sync to do an unnecessary resynchronisation, or, if resync was turned off, to jump out of sync. This is a long-standing bug – thanks to [Jörg Krause](https://github.com/joerg-krause) for identifying it. * An extra diagnostic has been added which gives the mean, standard deviation and maximum values for inter-packet reception time on the audio port. It may be useful for exploring line quality. Version 2.9.1 – Development Version ---- Version 2.9.1 focusses on bug fixes and stability improvements. * Stability improvements are concentrated on what happens when a play sessions ends and is followed immediately by a new session. This happens in iOS 9.2 when you click to the next track or to the previous track. It also happens playing YouTube videos when a Mac's System Audio is routed through AirPlay. Thanks to [Tim Curtis](https://github.com/moodeaudio) for help with these issues. * A workaround for an apparent flushing issue in TuneBlade has been included. Thanks to [gibman](https://github.com/gibman) for reporting this issue. * A number of bug fixes have been made to `configure.ac` – thanks to [Jörg Krause](https://github.com/joerg-krause). Version 2.8 – Stable Version ---- Version 2.8 is derived from version 2.7.10 with slight documentation updates. Here is a summary of changes between the last stable version – 2.6 – and this version. For full details, refer to the release notes here, back as far as 2.7. **New Feature** * For hardware mixers with a restricted range (including many cheaper USB DACS), the general `volume_range_db` can be used to specify a wider range than the hardware provides – the extra range is provided by software. **Enhancements** * The `man` manual and the html version of it are automagically rebuilt if `xml2man` and friends are available. * Volume-setting metadata is now sent even when the volume level is to be ignored by Shairport Sync itself. * Shairport Sync waits a little longer before asking for missing packets to be resent. Sometimes packets are just arriving slightly out of order and don't need to be asked for again. * The build scripts have been modified to be a little more compatible with standard practice. * A Continuous Integration (CI) system – Travis CI – is now used to do some limited build checking (thanks guys!). * Support added for compiling on Cygwin. * Added `rtptime` tags to metadata and picture metadata. * Replaced and improved the dither algorithm used with the software volume control. The new dither code gives a two bit peak-to-peak dither based on a Triangular Probability Distribution Function (TPDF). * Disabled picture sending if pictures haven’t been asked for. **Bug fixes** * Fixed a bug that prevented Shairport Sync from correctly setting the hardware mixer volume if it had been altered externally. Thanks to [Tim Curtis](https://github.com/moodeaudio) for help with these issues. * Modified the shutdown behaviour so that a shutdown followed immediately by a play request is handled better. This was causing iOS 9.2 sometimes to drop the Airplay link between tunes. * Fixed a data-alignment bug that would cause a crash in certain circumstances on ARM processors with metadata enabled. * Corrected the names for a few settings tags. * Fixed some typos and misspellings. * Miscellaneous small bug fixes. Version 2.7.10 -- Development Version ---- **New Feature** * If the `ignore_volume_control` setting was `yes`, Shairport Sync really did ignore volume control settings and did not send any volume metadata (i.e. `pvol` coded metadata). Now, while continuing to ignore volume control settings, it sends a `pvol` token where the first number is the AirPlay volume, as before, but the remaining three parameters are set to zero. Version 2.7.9 -- Development Version ---- **Bug Fix** * Oops – brown-bag update. Fixed a crashing bug introduced in the last release, caused by not checking for a hardware mixer before trying to access it, duh. Version 2.7.8 -- Development Version ---- **Bug Fix** * Fixed an issue whereby Shairport Sync did not reset the hardware mixer volume level before resuming playing. The issue was caused by not releasing and later reaquiring the mixer when pausing and resuming. Thanks to [Tim Curtis](https://github.com/moodeaudio) for reporting the issue. Version 2.7.7 -- Development Version ---- **Enhancements** * Add note about the Arch Linux Community repository package `shairport-sync`. Thanks to [Anatol Pomozov](https://github.com/anatol). * Shairport Sync doesn't ask for packets to be resent quite so quickly -- it waits about half a second now before asking for missing packets to be resent. **Bug Fixes** * Improved Shairport Sync's behaviour when it's asked to stop a play session and immediately start another. The signalling system used to stop threads was sometimes stopping threads belonging to the new session. This affected iOS 9.2 users going to the next track -- sometimes the player would become unavailable for an instant and disconnect the session. Th problem still happens occasionally. * Removed code favouring the use of "public" IPv6 addresses as source addresses when connecting to a distant IPv6 port – Neither OpenWrt nor FreeBSD can use it at present. Also, it's not clear if any problems are being caused by not favouring public IPv6 addresses. Version 2.7.6 -- Development Version ---- **Bug Fixes** * Look for the correct tag name for desired `ao` buffer length: `audio_backend_buffer_desired_length` rather than `audio_backend_buffer_desired_length_software`. * Fix a few FreeBSD compilation bugs. * Fix a few documentation issues and typos. Thanks to [Chris Boot](https://github.com/bootc). **Enhancements** * Add note about installing to Mac OS X. Thanks to [Serg Podtynnyi](https://github.com/shtirlic). * Add automatic rebuild of manpage and html documentation when `xmltoman` and friends are available. Thanks to [Chris Boot](https://github.com/bootc). * Favour the use of "public" IPv6 addresses as source addresses when connecting to a distant IPv6 port. Version 2.7.5 -- Development Version ---- **New Features** * Ubuntu PPA files now available at https://launchpad.net/~dantheperson. **Enhancements** * Broaden the use of the value `$PREFIX` instead of the path `/usr/local/bin` during configuration. Thanks to [dantheperson](https://github.com/dantheperson). Version 2.7.4 -- Development Version ---- **Enhancements** * Use the correct method for finding the `systemd` unit path, as recomended by debain maintainers and http://www.freedesktop.org/software/systemd/man/daemon.html#Installing%20Systemd%20Service%20Files. Thanks to [dantheperson](https://github.com/dantheperson). * Rather than hardwire the path `/usr/local/bin` as the path to the shairport-sync executable, the value of `$PREFIX` is now used during configuration. Thanks to [Nick Steel](https://github.com/kingosticks). * Add some extra diagnostic messages if the hardware buffer in the DAC is smaller than desired. * If metadata has been enabled, but if picture sending has not been requested and the source sends pictures anyway, omit them from the metadata feed. Thanks to [Jörg Krause](https://github.com/joerg-krause). **Bug Fixes** * Fixed a data alignment issue in the handling of metadata on some processors. Thanks to [Jörg Krause](https://github.com/joerg-krause). * Removed an `assert` which would terminate the program if a malformed packet of data was received. * Look for the correct tag name for desired alsa buffer length: `audio_backend_buffer_desired_length` rather than `audio_backend_buffer_desired_length_software`. Version 2.7.3 -- Development Version ---- **Bug Fix** * The dither code was broken in Shairport Sync and also less than ideal anyway. Fixed and improved. Dither is added whenever you use the software volume control at less than full volume. See http://www.ece.rochester.edu/courses/ECE472/resources/Papers/Lipshitz_1992.pdf for a very influential paper by Lipshitz, Wannamaker and Vanderkooy, 1992. The dither code in Shairport Sync was inherited from Shairport and does not conform to the recommendations in the paper -- specifically the implementation would give one bit of dither where the paper recommends two bits peak-to-peak. The other thing is that the inherited dither code was actually broken in Shairport Sync. So, the new dither code gives a two bit peak-to-peak dither based on a Triangular Probability Distribution Function (TPDF). It sounds like a very low-level white noise, unmodulated by the audio material. It would be nice if it was even lower, but it's better than listening to the artifacts present when dithering is disabled. Version 2.7.2 -- Development Version ---- **Bug Fix** * Fix a bug that suppressed output of the `rtptime` associated with metadata and with picture information coming from the audio source and passed on via the metadata pipe. **Other Changes** * Added some more information to the log whenever problems are detected with the proposed alsa device. Version 2.7.1 -- Development Version ---- **Bug Fix** * The new volume-extension code was not correctly setting the volume after a pause / resume. Fixed. Version 2.7 -- Development Version ---- **New Features** * Extend the volume range for some DACs. Background: some of the cheaper DACS have a very small volume range (that is, the ratio of the highest to the lowest volume, expressed in decibels, is very small). In some really cheap DACs it's only around 30 dB. That means that the difference betweeen the lowest and highest volume settings isn't large enough. With the new feature, if you set the `general` `volume_range_db` to more than the hardware mixer's range, Shairport Sync will combine the hardware mixer's range with a software attenuator to give the desired range. For example, suppose you want a volume range of 70 dB and the hardware mixer offers only 30 dB, then Shairport Sync will make up the other 40 dB with a software attenuator. One drawback is that, when the volume is being changed, there may be a slight delay (0.15 seconds by default) as the audio, whose volume may have been adjusted in software, propagates through the system. Another slight possible drawback is a slightly heavier load on the processor. * Check for underflow a little better when buffer aliasing occurs on very bad connections... * Add extra debug messages to the alsa back end to diagnose strange DACs. * Add configuration file for the `libao` back end -- to change the buffer size and the latency offset, same as for stdout. * Add `shairport-sync.exe` to `.gitignore`. * Add a check to support compilation on a CYGWIN platform. * Add `rtptime` tags to metadata and picture information and add two new metadata items to precede and follow the transmission of a picture. Background: it seems that metadata and picture information for the same item, e.g. a track, are normally tagged with a timestamp called the `rtptime`; if they refer to the same item, they will have the same `rtptime` tags. The update here is to add the `rtptime` value, if available, as data to the `mdst` and `mden` metadata items, which are sent before ("MetaData STart") and after ("MetaData ENd") a metadata sequence. In addition, similar tags -- `pcst` ("PiCture STart") and `pcen` ("PiCture ENd") are now sent before and after a picture with the `rtptime` value, if available, sent as data. By the way, the progress metadata (`prgr` for "PRoGRess"), which is sent just when a track starts, contains the same `rtptime` as its middle element. Version 2.6 -- Stable Version ---- This is basically version 2.4.2 with two small fixes. It's been bumped to 2.6 because (1) the new features added between 2.4.1 and 2.4.2 deserve more than just a bug-fix increment and (2) the development versions (2.5.x) should have lower numbers than the release versions, so that releases are always seen as upgrades. For example: 2.5.0.9 --> 2.6 looks like an upgrade, whereas 2.5.0.9 --> 2.4.2 looks like a downgrade. **Fixes** * For `systemd` users, the `shairport-sync.service` file is updated to point to the correct location of the shairport-sync application. * For Fedora users, the `shairport-sync.spec` file is updated to refer to 2.6. Version 2.4.2 ---- This release has important enhancements, bug fixes and documentation updates. It also appears to bring compatiblity with Synology NAS devices. **New Features** * Source-specified Latencies. Shairport Sync now uses the latencies specified by the audio source. Background: the AirPlay protocol used by Shairport Sync allows the audio source to specify the exact delay or latency that should be applied to the audio stream. Until now, Shairport Sync ignored this information and used fixed preset latencies that were selected on the basis of the "User-Agent" setting. Using source-specified latencies means that Shairport Sync is able adapt automatically to different sources. Using source-specified latencies is now automatic unless non-standard static latencies have been specified in the configuration file or command line. Using non-standard latencies is usually done to compensate for delays in the back end of the system. For example, if the audio amplifier being driven by Shairport Sync has an inherent delay of its own -- as happens with many home theatre and surround sound systems -- then some users have reduced the latencies used by Shairport Sync to compensate. This usage is discouraged -- the `audio_backend_latency_offset` in the appropriate backend stanza (e.g. in the "alsa" stanza) should be used for this. Static latency settings are now deprecated, and will be removed in a future version of Shairport Sync. * Set Volume Range. This is a new setting that allows you to use just a portion of the full range of attenuation offered by a mixer. 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. It is for this reason that many domestic HiFi systems have a volume control range of only 60 to 80 dB. Another possible reason to use this setting might be because the range specified by the mixer does not match the actual capabilities of the device. For example, the Raspberry Pi's DAC that feeds the built-in audio jack claims a range of 106 dB but has a useful range of only about 35dB. The new `volume_range_db` setting in the `general` stanza allows you to specify the maximum range from highest to lowest. The range suggested for the Raspberry Pi's built-in audio DAC, which feeds the headphone jack, is 35. Using it in this case gives the volume control a much more useful range of settings. **Bug fixes** * Sometimes, especially when using Shairport Sync as a system output, it would not play the audio stream. This was caused by an improperly initialised variable. Fixed. Synology NAS devices now seem to be working with Shairport Sync. * Fix in the `shairport.c`: the USE_CUSTOM_LOCAL_STATE_DIR macro was still being used when it should have been USE_CUSTOM_PID_DIR. * Fix a crashing bug -- if metadata was enabled but a pipename was not supplied, boom. **Other Changes** * Initial timing accuracy improved. The estimate of when to play the starting frame of the audio sequence has improved significantly. This leads to fewer corrections being needed at the start. * Volume ratios expressed in decibels are now consistently denominated in voltage decibels rather than power decibels. The rationale is that the levels refer to voltage levels, and power is proportional to the square of voltage. Thus a ratio of levels of 65535 to 1 is 96.3 dB rather than the 48.15 dB used before. * The latency figure returned to the source as part of the response to an rtsp request packet is 11,025, which may (?) be meant to indicate the minimum latency the device is capable of. * An experimental handler for a GET_PARAMETER rtsp request has been added. It does nothing except log the occurence. * The RTSP request dispatcher now logs an event whenever an unrecognised rtsp has been made. Version 2.4.1 ---- This release has three small bug fixes and some small documentation updates. **Bug Fixes** Changes from the previous stable version -- 2.4 -- are summarised here: * The USE_CUSTOM_LOCAL_STATE_DIR macro was still being used when it should have been USE_CUSTOM_PID_DIR. This could affect users using a custom location for the PID directory. * A compiler error has been fixed that occured if metadata was enabled and tinysvcmdns was included. * A crash has been fixed that occured if metadata was enabled and a metadata pipename was not specified. (Thanks to the contributors who reported bugs.) **Small Changes** * If a mixer being used to control volume does not have a control denominated in dB, a warning is logged and the mixer is not used. * Slight revisions have been made to the configuration file `configure.ac` to make compilation on FreeBSD a little easier. Version 2.4 ---- **Stable release** This stable release is the culmination of the 2.3.X sequence of development releases. **Change Summary** Changes from the previous stable version -- 2.2.5 -- are summarised here: * Settings are now read from a configuration file. Command-line settings are supported but discouraged. * Metadata is now supported -- it can be delivered to a unix pipe for processing by a helper application. See https://github.com/mikebrady/shairport-sync-metadata-reader for a sample metadata reader. * Raw PCM audio can be delivered to standard output ("stdout") or to a unix pipe. The internal architecture has changed considerably to support this. * Support for compilation on OpenWrt back to Attitude Adjustment. * Can play unencrypted audio streams -- complatible with, e.g. Whaale. * Uses the libconfig library. * Runs on a wider range of platforms, including Arch Linux and Fedora. * Bug fixes. Please note that building instructions have changed slightly from the previous version. Also, the `-t hardware/software` option has been deprecated in the alsa back end. Version 2.3.13 ---- **Note** * We're getting ready to release the development branch as the new, stable, master branch at 2.4. If you're packaging Shairport Sync, you might prefer to wait a short while as we add a little polish before the release. **Changes** * Harmonise version numbers on the release and on the `shairport.spec` file used in Fedora. Version 2.3.12 ---- **Note** * We're getting ready to release the development branch as the new, stable, master branch at 2.4. If you're packaging Shairport Sync, you might prefer to wait a short while as we add a little polish before the release. **Changes** * `update-rc.d` has been removed from the installation script for System V because it causes problems for package makers. It's now noted in the user installation instructions. * The `alsa` group `mixer_type` setting is deprecated and you should stop using it. Its functionality has been subsumed into `mixer_name` – when you specify a `mixer_name` it automatically chooses the `hardware` mixer type. **Enhancements** * Larger range of interpolation. Shairport Sync was previously constrained not to make interpolations ("corrections") of more than about 1 per 1000 frames. This contraint has been relaxed, and it is now able to make corrections of up to 1 in 352 frames. This might result in a faster and undesirably sudden correction early during a play session, so a number of further changes have been made. The full set of these changes is as follows: * No corrections happen for the first five seconds. * Corrections of up to about 1 in 1000 for the next 25 seconds. * Corrections of up to 1 in 352 thereafter. **Documentation Update** * Nearly there with updates concerning the configuration file. Version 2.3.11 ---- Documentation Update * Beginning to update the `man` document to include information about the configuration file. It's pretty sparse, but it's a start. Version 2.3.10 ---- Bug fix * The "pipe" backend used output code that would block if the pipe didn't have a reader. This has been replaced by non-blocking code. Here are some implications: * When the pipe is created, Shairport Sync will not block if a reader isn't present. * If the pipe doesn't have a reader when Shairport Sync wants to output to it, the output will be discarded. * If a reader disappears while writing is occuring, the write will time out after five seconds. * Shairport Sync will only close the pipe on termination. Version 2.3.9 ---- * Bug fix * Specifying the configuration file using a *relative* file path now works properly. * The debug verbosity requested with `-v`, `-vv`, etc. is now honoured before the configuration file is read. It is read and honoured from when the command line arguments are scanned the first time to get a possible configuration file path. Version 2.3.8 ---- * Annoying changes you must make * You probably need to change your `./configure` arguments. The flag `with-initscript` has changed to `with-systemv`. It was previously enabled by default; now you must enable it explicitly. * Changes * Added limited support for installing into `systemd` and Fedora systems. For `systemd` support, use the configuration flag `--with-systemd` in place of `--with-systemv`. The installation does not do everything needed, such as defining special users and groups. * Renamed `with-initscript` configuration flag to `with-systemv` to describe its role more accurately. * A System V startup script is no longer installed by default; if you want it, ask for it with the `--with-systemv` configuration flag. * Added limited support for FreeBSD. You must specify `LDFLAGS='-I/usr/local/lib'` and `CPPFLAGS='-L/usr/local/include'` before running `./configure --with-foo etc.` * Removed the `-configfile` annotation from the version string because it's no longer optional; it's always there. * Removed the `dummy`, `pipe` and `stdout` backends from the standard build – they are now optional and are no longer automatically included in the build. * Bug fixes * Allow more stack space to prevent a segfault in certain configurations (thanks to https://github.com/joerg-krause). * Add missing header files(thanks to https://github.com/joerg-krause). * Removed some (hopefully) mostly silent bugs from the configure.ac file. Version 2.3.7 ---- * Changes * Removed the two different buffer lengths for the alsa back end that made a brief appearance in 2.3.5. * Enhancements * Command line arguments are now given precedence over config file settings. This conforms to standard unix practice. * A `–without-pkg-config` configuration argument now allows for build systems, e.g. for older OpenWrt builds, that haven't fully implemented it. There is still some unhappiness in arch linux builds. * More * Quite a bit of extra diagnostic code was written to investigate clock drift, DAC timings and so on. It was useful but has been commented out. If might be useful in the future. Version 2.3.5 ---- * Changes * The metadata item 'sndr' is no longer sent in metadata. It's been replaced by 'snam' and 'snua' -- see below. * Enhancements * When a play session is initiated by a source, it attempts to reserve the player by sending an "ANNOUNCE" packet. Typically, a source device name and/or a source "user agent" is sent as part of the packet. The "user agent" is usually the name of the sending application along with some more information. If metadata is enabled, the source name, if provided, is emitted as a metadata item with the type `ssnc` and code `snam` and similarly the user agent, if provided, is sent with the type `ssnc` and code `snua`. * Two default buffer lengths for ALSA -- default 6615 frames if a software volume control is used, to minimise the response time to pause and volume control changes; default 22050 frames if a hardware volume control is used, to give more resilience to timing problems, sudden processor loading, etc. This is especially useful if you are processing metadata and artwork on the same machine. * Extra metadata: when a play session starts, the "Active-Remote" and "DACP-ID" fields -- information that can be used to identify the source -- are provided as metadata, with the type `ssnc` and the codes `acre` and `daid` respectively. The IDs are provided as strings. * Unencrypted audio data. The iOS player "Whaale" attempts to send unencrypted audio, presumably to save processing effort; if unsuccessful, it will send encrypted audio as normal. Shairport Sync now recognises and handles unencrypted audio data. (Apparently it always advertised that it could process unencrypted audio!) * Handle retransmitted audio in the control channel. When a packet of audio is missed, Shairport Sync will ask for it to be retransmitted. Normally the retransmitted audio comes back the audio channel, but "Whaale" sends it back in the control channel. (I think this is a bug in "Whaale".) Shairport Sync will now correctly handle retransmitted audio packets coming back in the control channel. * Bugfixes * Generate properly-formed `..` items of information. Version 2.3.4 ---- * Enhancement * When a play session starts, Shairport Sync opens three UDP ports to communicate with the source. Until now, those ports could be any high numbered port. Now, they are located within a range of 100 port locations starting at port 6001. The starting port and the port range are settable by two new general settings in `/etc/shairport-sync.conf` -- `udp_port_base` (default 6001) and `udp_port_range` (default 100). To retain the previous behaviour, set the `udp_port_base` to `0`. * Bugfixes * Fix an out-of-stack-space error that can occur in certain cases (thanks to https://github.com/joerg-krause). * Fix a couple of compiler warnings (thanks to https://github.com/joerg-krause). * Tidy up a couple of debug messages that were emitting misleading information. Version 2.3.3.2 ---- * Bugfix -- fixed an error in the sample configuration file. Version 2.3.3.1 ---- * Enhancement * Metadata format has changed slightly -- the format of each item is now `........`, where the `..` part is present if the length is non-zero. The change is that everything is now enclosed in an `..` pair. Version 2.3.2 and 2.3.3 ---- These releases were faulty and have been deleted. Version 2.3.1 ----- Some big changes "under the hood" have been made, leading to limited support for unsynchronised output to `stdout` or to a named pipe and continuation of defacto support for unsynchronised PulseAudio. Also, support for a configuration file in preference to command line options, an option to ignore volume control and other improvements are provided. In this release, Shairport Sync gains the ability to read settings from `/etc/shairport-sync.conf`. This gives more flexibility in adding features gives better compatability across different versions of Linux. Existing command-line options continue to work, but some will be deprecated and may disappear in a future version of Shairport Sync. New settings will only be available via the configuration file. Note that, for the present, settings in the configuration will have priority over command line options for Shairport Sync itself, in contravention of the normal unix convention. Audio back end command line options, i.e. those after the `--`, have priority over configuration file settings for the audio backends. In moving to the the use of a configuration file, some "housekeeping" is being done -- some logical corrections and other small changes are being made to option names and modes of operations, so the settings in the configuration file do not exactly match command line options. When `make install` is executed, a sample configuration is installed or updated at `/etc/shairport-sync.conf.sample`. The same file is also installed as `/etc/shairport-sync.conf` if that file doesn't already exist. To prevent the configuration files being installed, use the configuration option `--without-configfiles`. * Pesky Change You Must Do Something About If you are using metadata, please note that the option has changed somewhat. The option `-M` has a new long name equivalent: `--metadata-pipename` and the argument you provide must now be the full name of the metadata pipe, e.g. `-M /tmp/shairport-sync-metadata`. * Enhancements * Shairport Sync now reads settings from the configuration file `/etc/shairport-sync.conf`. This has settings for most command-line options and it's where any new settings will go. A default configuration file will be installed if one doesn't exist, and a sample file configuration file is always installed or updated. Details of settings are provided in the sample file. Shairport Sync relies on the `libconfig` library to read configuration files. For the present, you can disable the new feature (and save the space taken up by `libconfig`) by using the configure option `--without-configfile-support`. * New command-line option `-c ` or `--configfile=` allows you to specify a configuration file other than `/etc/shairport-sync.conf`. * Session Timeout and Allow Session Interruption can now be set independently. This is really some "housekeeping" as referred to above -- it's a kind of a bug fix, where the bug in question is an inappropriate connection of the setting of two parameters. To explain: (1) By default, when a source such as iTunes starts playing to the Shairport Sync device, any other source attempting to start a play session receives a "busy" signal. If a source disappears without warning, Shairport Sync will wait for 120 seconds before dropping the session and allowing another source to start a play session. (2) The command-line option `-t` or `--timeout` allows you to set the wait time before dropping the session. If you set this parameter to `0`, Shairport Sync will not send a "busy" signal, thus allowing another source to interrupt an existing one. (3) The problem is that if you set the parameter to `0`, a session will never be dropped if the source disappears without warning. The (obvious) fix for this is to separate the setting of the two parameters, and this is now done in the configuration file `/etc/shairport-sync.conf` -- please see the settings `allow_session_interruption` and `session_timeout`. The behaviour of the `-t` and `--timeout` command-line options is unchanged but deprecated. * New Option -- "Ignore Volume Control" ('ignore_volume_control'). If you set this to "yes", the output from Shairport Sync is always set at 100%. This is useful when you want to set the volume locally. Available via the settings file only. * Statistics option correctly reports when no frames are received in a sampling interval and when output is not being synchronised. * A new, supported audio back end called `stdout` provides raw 16-bit 44.1kHz stereo PCM output. To activate, set `output_backend = "stdout"` in the general section of the configuration file. Output is provided synchronously with the source feed. No stuffing or stripping is done. If you are feeding it to an output device that runs slower or faster, you'll eventually get buffer overflow or underflow in that device. To include support for this back end, use the configuration option `--with-stdout`. * Support for the `pipe` back end has been enhanced to provide raw 16-bit 44.1kHz stereo PCM output to a named pipe. To activate, set `output_backend = "pipe"` in the general section of the configuration and give the fully-specified pathname to the pipe in the pipe section of the configuration file -- see `etc/shairport-sync.conf.sample` for an example. No stuffing or stripping is done. If you are feeding it to an output device that runs slower or faster, you'll eventually get buffer overflow or underflow in that device. To include support for this back end, use the configuration option `--with-pipe`. * Support for the `dummy` audio backend device continues. To activate, set `output_backend = "dummy"` in in the general section of the configuration. To include support for this back end, use the configuration option `--with-dummy`. * Limited support for the PulseAudio audio backend continues. To activate, set `output_backend = "pulse"` in in the general section of the configuration. You must still enter its settings via the command line, after the `--` as before. Note that no stuffing or stripping is done: if the PulseAudio sink runs slower or faster, you'll eventually get buffer overflow or underflow. * New backend-specific settings are provided for setting the size of the backend's buffer and for adding or removing a fixed offset to the overall latency. The `audio_backend_buffer_desired_length` default is 6615 frames, or 0.15 seconds. On some slower machines, particularly with metadata processing going on, the DAC buffer can underflow on this setting, so it might be worth making the buffer larger. A problem on software mixers only is that changes to volume control settings have to propagate through the buffer to be heard, so the larger the buffer, the longer the response time. If you're using an alsa back end and are using a hardware mixers, this isn't a problem. The `audio_backend_latency_offset` allows you emit frames to the audio back end some time before or after the synchronised time. This would be useful, for example, if you are outputting to a device that takes 20 ms to process audio; yoou would specify a `audio_backend_latency_offset = -882`, where 882 is the number of frames in 20 ms, to compensate for the device delay. Version 2.3 ----- * Enhancements * Adding the System V startup script (the "initscript") is now a configuration option. The default is to include it, so if you want to omit the installation of the initscript, add the configuration option `--without-initscript`. * Metadata support is now a compile-time option: `--with-metadata`. * A metadata feed has been added. Use the option `-M `, e.g. `-M /tmp`. Shairport Sync will provide metadata in a pipe called `/shairport-sync-metadata`. (This is changed in 2.3.1.) There's a sample metadata reader at https://github.com/mikebrady/shairport-sync-metadata-reader. The format of the metadata is a mixture of XML-style tags, 4-character codes and base64 data. Please look at `rtsp.c` and `player.c` for examples. Please note that the format of the metadata may change. Beware: there appears to be a serious bug in iTunes before 12.1.2, such that it may stall for a long period when sending large (more than a few hundred kilobytes) coverart images. * Bugfix * Fix a bug when compiling for Arch Linux on Raspberry Pi 2 (thanks to https://github.com/joaodriessen). * Fix a bug whereby if the ANNOUNCE and/or SETUP method fails, the play_lock mutex is never unlocked, thus blocking other clients from connecting. This can affect all types of users, but particularly Pulseaudio users. (Thanks to https://github.com/jclehner.) * Modify the init script to start after all services are ready. Add in a commented-out sleep command if users find it necessary (thanks to https://github.com/BNoiZe). * Two memory leaks fixed (thanks to https://github.com/pdgendt). * An error handling time specifications for flushes was causing an audible glitch when pausing and resuming some tracks. This has been fixed (thanks to https://github.com/Hamster128). Version 2.2.5 ----- * Bugfixes * Fix a segfault error that can occur in certain cases (thanks again to https://github.com/joerg-krause). * Include header files in common.c (thanks again to https://github.com/joerg-krause). Version 2.2.4 ----- * Bugfixes * Fix an out-of-stack-space error that can occur in certain cases (thanks to https://github.com/joerg-krause). * Fix a couple of compiler warnings (thanks to https://github.com/joerg-krause). Version 2.2.3 ----- * NOTE: all the metadata stuff has been moved to the "development" branch. This will become the stable branch henceforward, with just bug fixes or minor enhancements. Apologies for the inconvenience. * Bugfixes * Fix a bug when compiling for Arch Linux on Raspberry Pi 2 (thanks to https://github.com/joaodriessen). * Fix a compiler warning (thanks to https://github.com/sdigit). Version 2.2.2 ----- * Enhancement * An extra latency setting for forked-daapd sources -- 99,400 frames, settable via a new option `--forkedDaapdLatency`. Version 2.2.1 ----- * Bugfixes: * If certain kinds of malformed RTSP packets were received, Shairport Sync would stop streaming. Now, it generally ignores faulty RTSP packets. * The `with-pulseaudio` compile option wasn't including a required library. This is fixed. Note that the PulseAudio back end doesn't work properly and is just included in the application because it was there in the original shairport. Play with it for experimentation only. * Fix typo in init.d script: "Headphones" -> "Headphone". * Extra documentation * A brief note on how to compile `libsoxr` from source is included for the Raspberry Pi. Version 2.2 ----- * Enhancements: * New password option: `--password=SECRET` * New tolerance option: `--tolerance=FRAMES`. Use this option to specify the largest synchronisation error to allow before making corrections. The default is 88 frames, i.e. 2 milliseconds. The default tolerance is fine for streaming over wired ethernet; however, if some of the stream's path is via WiFi, or if the source is a third-party product, it may lead to much overcorrection -- i.e. the difference between "corrections" and "net correction" in the `--statistics` option. Increasing the tolerence may reduce the amount of overcorrection. Version 2.1.15 ----- * Changes to latency calculations: * The default latency is now 88,200 frames, exactly 2 seconds. It was 99,400 frames. As before, the `-L` option allows you to set the default latency. * The `-L` option is no longer deprecated. * The `-L` option no longer overrides the `-A` or `-i` options. * The default latency for iTunes is now 99,400 frames for iTunes 10 or later and 88,200 for earlier versions. * The `-i` or `--iTunesLatency` option only applies to iTunes 10 or later sources. Version 2.1.14 ----- * Documentation update: add information about the `-m` audio backend option. The `-m` audio backend option allows you to specify the hardware mixer you are using. Not previously documented. Functionality of shairport-sync is unchanged. Version 2.1.13 ----- * Compilation change: Begin to use PKG_CHECK_MODULES (in configure.ac) to statically link some of the libraries used by shairport-sync. It is intended to make it easier to build in the buildroot system. While sufficient for that purpose, note that PKG_CHECK_MODULES is not used for checking all the libraries yet. Functionality of shairport-sync is unchanged. Version 2.1.12 ----- * Enhancement: `--statistics` Statistics are periodically written to the console (or the logfile) if this command-line option is included. They are no longer produced in verbose (`-v`) mode. * Bugfixes for `tinysvcmdns` * A bug that prevented the device's IP number(s) and port numbers being advertised when using `tinysvcmdns` has been fixed. (Cause: name needed to have a `.local` suffix.) * Bugs causing the shairport service to semi-randomly disappear and reappear seem to be fixed. (Possible cause: incorrect timing settings when using `tinysvcmdns`.) Version 2.1.11 ----- * Enhancement * A man page is now installed -- do `man shairport-sync` or see it here: http://htmlpreview.github.io/?https://github.com/mikebrady/shairport-sync/blob/2.1/man/shairport-sync.html. Version 2.1.10 ----- * Bugfix * A bug that caused the `-t` timeout value to be incorrectly assigned has been fixed. (Cause: `config.timeout` defined as `int64_t` instead on `int`.) Version 2.1.9 ----- * Bugfixes * A bug that sometimes caused the initial volume setting to be ignored has been fixed. (Cause: setting volume before opening device.) * a bug that caused shairport-sync to become unresponsive or unavailable has been fixed. (Cause: draining rather than flushing the alsa device before stopping.) Version 2.1.8: ----- * Enhancements * (This feature is intended to be useful to integrators.) Shairport Sync now the ability to immediately disconnect and reconnect to the sound output device while continuing to stream audio data from its client. Send a `SIGUSR2` to the shairport-sync process to disconnect or send it a `SIGHUP` to reconnect. If shairport-sync has been started as a daemon using `shairport-sync -d`, then executing `shairport-sync -D` or `--disconnectFromOutput` will request the daemon to disconnect, and executing `shairport-sync -R` or `--reconnectToOutput` will request it to reconnect. With this feature, you can allow Shairport Sync always to advertise and provide the streaming service, but still be able to disconnect it locally to enable other audio services to access the output device. * Annoying things you should know about if you're updating from a previous version: * Options `--with-openssl`, `--with-polarssl` have been replaced with a new option `--with-ssl=