What's New

[mikebrady]

October 28, 2022

Update : this problem from iOS 16.0 seems to be gone from iOS 16.1, iPadOS 16.1 and Ventura:

September 15, 2022. iOS 16.0 and iPodOS 16.0 have a rather odd new behaviour in AirPlay 2: re-sending frames of audio with the same timestamps. To be exact, in a buffered audio session, 2,112 frames of audio are often transmitted a second time around half a second after the session starts. The effect is to throw synchronisation off by a delay of 2,112 frames -- about 48 milliseconds.

September 26, 2022

Finally, a Release Candidate! Yes, Version 4.1-rc0 is out on the master branch as a prerelease. Thanks to everyone who has contributed to this -- it's been a long process. With sincere apologies to William Butler Yeats (again):

"And what rough beast, its hour come round at last,
Slouches towards GitHub to be born?"

September 23, 2022

A number of approaches have been tried to fix that apparent bug in iOS 16.0 (and iOS 16.0.2). The most aurally successful is left in the code but is disabled. Basically, it would delay the timing of the frames following the 2,112 frame discontinuity by 2,112 frames. This eliminates the timing discontinuity but delays the AirPlay stream by 47.9 ms, and this can be heard in some situations. So it looks as if the bug -- if that's what it is -- can't easily be worked around. It has not been fixed by iOS 16.0.2, unfortunately.

September 15, 2022

iOS 16.0 and iPodOS 16.0 have a rather odd new behaviour in AirPlay 2: re-sending frames of audio with the same timestamps. To be exact, in a buffered audio session, 2,112 frames of audio are often transmitted a second time around half a second after the session starts. The effect is to throw synchronisation off by a delay of 2,112 frames -- about 48 milliseconds. This may trigger a resync event by Shairport Sync (the threshold is 50 ms.) but full sync is generally recovered smoothly over about 30 seconds. Other discontinuities have been observed around the start of a session. They don't seem to be repeatable.

Overall, it looks like a bug, and hopefully will be resolved soon. If not, then we'll see what can be done to work around it.

Ventura, HomePod mini and tvOS have not been tested.

July 25, 2022

Today brings a long-overdue reorganisation of the documentation in the repository. The intention is to keep the documents as compact as possible, avoiding duplication and highlighting extra features in a non-offputting manner. When the release rolls around – soon, hopefully, as the documentation was the main stumbling block recently – the superseded documents will be removed.

Your comments, corrections and suggestions would be welcome.

June 25, 2022

Recent updates to NQPTP and Shairport Sync development branch have fixed an elusive but widespread problem: if you played some music, paused for a few minutes and then resumed, Shairport Sync would occasionally not resume. It seemed to happen with different clients, but it was quite ephemeral. It turns out that a player's synchronisation clock can sometimes stop running -- go to sleep, as it were, presumably to save energy -- and resume in the future having lost the time during which it was asleep. This would be fine, except that NQPTP had a bug in it that prevented it from adjusting to the new timing information. That is fixed now, as are a few bugs that prevented Shairport Sync from smoothly adjusting to the addition and removal of new AirPlay 2 devices.

Another development is that NQPTP and Shairport Sync, in AirPlay 2 mode, now compile and run on FreeBSD.

March 15, 2022

An update has been pushed to the development branch to fix a small incompatibility with HomePod Software 15.4. Specifically, the issue was that when a Shairport Sync device was added as a HomePod output device, it didn't appear to join the group of output devices. Additionally, its volume control could not be accessed.

January 13, 2022

You might be interested in testing out a new tool for exploring the alsa devices on a machine to determine if they might be suitable for use with Shairport Sync. It's called sps-alsa-explore and it's available here. Comments welcome!

January 2, 2022.

Multiple instances of Shairport Sync can run independently on the same device. You'll need to update both Shairport Sync and NQPTP. NQPTP can now deal with multiple independent clients by using individually-named shared memory interfaces and associated timing peer lists.

While multiple AirPlay 2 services can now be provided on one device, AirPlay 2 clients seem to be confused by multiple services being available at the same addresses.
You will have to update Shairport Sync to be compatible with this new version of NQPTP. (This is really for advanced users.)

December 16, 2021

• Remote Control is partly working! Sometime in the recent past, possibly with Apple's latest updates, Remote Control has started working. It seems to be a work in progress. A fairly complete set of the remote control features from iOS is working. A very small number of the remote control features in the macOS are also working, but the Advanced Remote Control features are completely missing. (See here for some more details.)
• The Apple updates (iOS 15.2, macOS 12.1, tvOS 15.2) seem to work well with Shairport Sync.

December 8, 2021

• A major under-the-hood update today. This update requires an updated nqptp because the timebase has been changed for improved stability and accuracy.

November 14, 2021

• With today's bug fix, the AirPlay 2 implementation in the development branch of Shairport Sync (along with the latest development branch of nqptp) works quite well with an Apple TV 4K. Reports welcome.

November 9, 2021

• The development branch of nqptp has been updated with a possible workaround for what appears to be an Apple bug. The bug (if that's what it is) stops some devices, including Shairport Sync devices, from playing after an Apple device wakens from sleep. This update seems to work around the bug.
• The development branch of Shairport Sync has been updated for compatibility with iOS 15.1 and macOS Monterey.