Whole-house audio with free hardware and software

The Black Forest fire destroyed over 500 Colorado houses in June 2013; one of those belonged to longtime Debian developer Bdale Garbee. As he reported during his talk at the 2016 linux.conf.au Multimedia and Music miniconf, the house has been redesigned and rebuilt and life is generally better now. Part of the rebuilding process included the incorporation of a whole-house audio system; naturally, Bdale took a unique approach to that task. His talk showed what can be done when one starts from scratch — and doesn't mind designing a circuit board along the way.

A common approach to whole-house audio is to use a network — typically WiFi — to distribute audio bits to various places within the house. Companies like Sonos and others happily sell that kind of system; there are, Bdale said, a number of free-software projects working to replicate those products. His approach was different, though. The system was designed around speakers built into the ceiling of each room; all are wired back to a central audio server installed in a mechanical closet. In other words, analog audio, rather than a digital stream, is distributed around the house.

There are plenty of proprietary products that follow that sort of design as well. They are typically built around a two-dimensional crossbar switch that can connect specific audio sources to any of a number of audio zones. He would have been happy enough with a proprietary solution, he said; in the end, it's just an appliance installed into the house. There was, though, one absolute deal-breaker: his due-diligence work turned up the existence of probable GPL-infringement issues with these products. Just reading the manuals was enough to make it clear that they were Linux-based, but there was no mention of software licenses, and no downloadable firmware in any form, much less source code. So some other sort of solution was called for.

The revised plan called for the builder to put in the speakers and wire them back to the central closet, but to install no server; Bdale would supply that part. He spent some time looking into commercially available amplifiers and switches, but he found them to be "clunky and expensive." The products were designed as if they were to be installed into professional recording studios; they had a level of complexity that he just didn't need. If only, he said, there were a nice USB-attached device with stereo output, the rest could easily be assembled from available hardware and software. Such things do exist, of course, but there were none that met his requirements; they required things like wall-wart power supplies, something that gets awkward when you mean to install nine of them. So he ended up designing his own hardware.

The result was the small board shown to the right. It features a PCM2705C digital-to-analog converter — essentially a USB stereo audio chip. Among its advantages are the fact that it already has good support in the Linux kernel. Tied to that is a TPA3118D2 class-D audio amplifier with 30 watts/channel of output power. Some of his audiophile friends evidently give him grief about using a class-D amplifier, but, he said, these amplifiers are good enough for a system built around ceiling-mounted speakers.

(Given that, as he said earlier in the talk, his previous office audio system was a tablet playing out of its built-in speaker, there can be no doubt that the new system sounds much better even if the gold-cable crowd would turn up its collective nose at it).

Nine of these modules (which go by the name usbclassd) are plugged into a MinnowBoard Max system. That board provides what's needed: a network interface and a USB port. The Intel architecture also seems to be important: some of the software components needed to obtain audio from commercial streaming services (he mentioned Spotify in particular) are binary-only. He is not entirely happy with that but, he said, keeping the family happy trumps adherence to open-source software principles.

The MinnowBoard is running a minimal Debian system; in general, he said, the earlier one can get out of the distribution's installer, the better. The directory tree for media is automounted (using NFS) from another server on the network. The audio software system is built around Mopidy. It was, he said, designed to be part of a desktop environment, so running it on this type of audio server is moving it a bit out of its native mode, but it works well enough. It supports the MPD protocol allowing for remote control, and has a web-interface protocol as well. He is not, he said, using Debian's packaged version of Mopidy since he needs the proprietary Spotify plugin which, naturally, Debian does not provide.

One interesting problem that had to be worked out is USB enumeration. The usbclassd boards are plugged into an inexpensive ten-port hub obtained online; those hubs, he said, are "randomly wired." The usbclassd boards lack unique serial IDs (something he could have added with another chip, but chose not to), so there is no way to tell them apart in the software. Fortunately, with a fixed hardware configuration, USB enumeration in the kernel is deterministic so, once he worked out which was which, it was a simple matter to map each device to the zone it serves.

One of the nice features of the amplifier he chose is that it can power down when the USB interface suspends itself. But, after realizing that those amplifiers were hot when no music was being played, he realized that things didn't quite work as he had expected. The USB audio interface doesn't suspend itself when there is no packet traffic; it depends on the suspend state of the interface in general. USB autosuspend tends not to be enabled by default, since there is a lot of second-rate hardware that doesn't support it well. His hardware does support it, though. A simple udev rule tweak was enough to get around that issue. It is still necessary to actually stop the audio stream out of Mopidy to get things to suspend, though; simply pausing it is not sufficient.

Getting back to Mopidy, he noted that it is designed to only support a single audio stream — a bit of a mismatch to his use case, with nine independent zones. His solution is to just run nine instances of Mopidy; it's a "clunky workaround," but it works. Each instance has its own MPD socket; the Mopidy Mobile app can be configured to know about all of the zones.

His final topic was clock skew. Digital audio interfaces work by streaming a series of samples to the digital-to-analog converter; that converter converts them to audio at the rate determined by the on-board clock. If you are feeding the same stream to multiple boards simultaneously, even small differences in the clock rate will accumulate over time. That can lead to the different zones being out of phase (an audiophile issue that Bdale found kind of laughable, especially given that the different zones are in different rooms) or eventual buffer underruns on the board with the faster clock. Bdale said that he could have gotten around this issue by creating a nine-output board with a single clock; a member of the audience suggested he could look into the clock synchronization support in GStreamer (which Mopidy uses). The simple fact, though, is that he doesn't really care about this issue. That could be reviewed if he ever develops the wish to drive multiple zones in parallel, but it is not an issue now.

The system is working, and the entire family seems to be happy with it. There are always improvements that can be made (he mentioned replacing the power-supply fan with "one that has ball bearings"), but, in a sense, the project can be seen as complete. For the curious, some more information, including schematics for the usbclassd board, can be found on his web site.

[Your editor thanks LCA for assisting with his travel expenses.]

Index entries for this article
Conference	linux.conf.au/2016

---

to post comments