-
-
Notifications
You must be signed in to change notification settings - Fork 572
Home
This project started when I saw reviews [May 14, 2014] for the Topping TP30, a low-cost HiFi amplifier with USB input. The reviews are generally excellent and it's pretty cheap, so I thought it would be nice to get a fully digital multi-room hifi system based around the TP30 and iTunes. I already have a couple of amplifiers connected to Airport Expresses around the house, and wanted to try my luck with this approach.
To summarize, what I wanted was:
- Fully digital end-to-end audio chain from iTunes to amplifier
- Full audio synchronisation
- Multiroom functionality
- Low hassle – something that "just works"(TM)
My plan was to take an embedded Linux device, such as a Raspberry Pi [May 14, 2014] or an [old!] Linksys NSLU2 [May 14, 2014] (a "slug"), connect it over Ethernet or WiFi, connect it to the USB port of the TP30 and run Shairport to make it visible as an output device in iTunes. I have some experience with OpenWrt, so I went looking for Shairport on OpenWrt.
I found a Shairport for OpenWrt at https://github.com/sm3rt/OpenWRT-ShairPort which uses https://github.com/abrasive/shairport. I managed to get this to compile against OpenWrt trunk with little difficulty — thanks guys — and installed it on an NSLU2, connected up and was up and running.
Well, it works great, but has a few issues for me:
- It doesn't synchronise with other audio devices. This is a deal breaker for me. If it won't work with other Airplay devices, it's no use. Shairport 1.0 offers an option – the number of buffers to look for before it starts playing. This sort-of works, but really sort-of doesn't. You can guess or estimate the right setting and Shairport will start more-or-less in sync with the other devices, but it won't stay in sync. So, a real deal breaker. Also, even if you could live with it, it's really messy.
- Laggy volume control. If you don't select the 'hardware' device type, Shairport 1.0's response to changes in volume is slow – alarmingly slow. Not a deal breaker though.
- Pause delay. If you pause a piece of music in iTunes, it could take an appreciable time for Shairport 1.0 to pause. Also not a deal breaker.
- No mute. Shairport emulates mute by setting the volume to its lowest value. On good stereos, however, you can still hear the sound, albeit faintly. Again, not a deal breaker.
- Poor volume adjustment. Normally, you'd expect the volume of the sound to rise fairly smoothly from a very low value to the highest, but Shairport 1.0 does a very poor job of this. Okay, I'm being a bit picky here.
Overall, a real deal breaker for me is the inability to have multi room operation. The other issues detract significantly from the overall experience, but would not be fatal on their own; they are in the "not good enough" category.
Digging into the code of Shairport 1.0 revealed that Shairport 1.0 doesn't use the extra timing information Apple added to AirTunes. (I think this may be because Shairport was written originally before the timing information was added in AirTunes 2.) The extra timing information could be used to synchronise playback accurately with the source, effectively "locking" playback to the source's timing.
Shairport 1.0 does try to get around the synchronisation problem by timing the average rate on reception of audio data. If it seems that the audio is arriving too quickly, then it's a sign that the clock Shairport's computer is using is running too slow, and vice versa. This information is used work out whether to remove or insert frames of audio into the audio stream going to the output device to keep pace with the incoming audio. Specifically, Shairport 1.0 has a pretty fancy low pass filter, based on a bi-quad filter, for averaging out small variations in the rate of incoming audio data. It also has code for inserting and removing frames of audio into the audio stream.
This approach has two problems, one of which is fatal, IMHO:
- The less-serious, but pesky, issue is that the 'slow' or 'fast' signal derived from the rate of incoming audio is multiplied by a control factor to govern how many frames to delete or insert -- if the factor is too high, it overcompensates and you get less-than-fully-faithful audio; if too low, it undercompensates and you lose synchronisation. The real kicker is: How do you set the value of the control factor?
- The fatal problem with this approach is that while the [apparent] rate of incoming audio is related to the rate at which Shairport's computer's clock is running, it is not necessarily related to the rate at which the audio card or output device is really consuming the data, as they may be running their own, independent, clocks. It is definitely not related to the clock rate of a USB-based DAC, so even if you get the control factor 'right', it's still useless.
Shairport 2.0 is based on Shairport 1.0 and is an attempt to address its shortcomings "properly", that is, in a principled way rather than as a kind of hack. The principal issue is, of course, the synchronisation problem. So Shairport 2.0 builds on Shairport 1.0 as follows:
- It asks for extra timing information from the iTunes / iOS source. A much simplified version of NTP clock synchronisation protocols is used to keep Shairport 2.0 in exact sync with the source.
- Shairport 2.0 gets extra timing information from the output device, so it can work out the exact time difference between incoming and outgoing audio. (For this reason, it only works with ALSA.)