Development – Unstable

Add timing request-return turnaround time to diagnostics.

Development – Unstable

Remove AC_CHECK_HEADER_STDBOOL check; OpenWrt doesn't like it.

Development – Unstable

Revert to using CLOCK_MONOTONIC from CLOCK_MONOTNIC_RAW – OpenWrt doesn't understand it.

Also update some checks in configure.ac.

Development – Unstable

Updating measurement code...

Development – Unstable

Improving statistics gathering in OpenWrt.

Development Version – Unstable

Has extra diagnostics for checking sources of drift for use in OpenWrt

Development Version – Very Unstable

Get the –with-pkg-config compile option working properly. Need to publish it as a release to test it on OpenWrt. Very unstable.

Version 2.3.5 – Development: Unencrypted Audio, Metadata Changes & Improvements

• 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 <item>..</item> items of information.

Version 2.3.4 – Development: Add UDP port numbering control.

Version 2.3.4

• Enhancement – Add UDP port numbering control
  • 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, by default, 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 – Development: configuration file fix.

Fixed a syntax error in the configuration file.