Linux for Suits - The Sound of Linux
On November 25, 2005, I wrote “Building an Open Source House” (see the on-line Resources) on the Linux Journal Web site. Mostly, I was looking for some last-minute (or -week) advice about equipment and wiring before we put up sheetrock at the new house we're building. We should be in the house by the time you read this. It will be our seventh home in seven years, and hopefully our last for a long time.
It's a dream home on a Santa Barbara hillside overlooking the town and the ocean. It's also a Faraday cage, with 11 tons of steel girders inside its walls and under its decks, thick fieldstone and stucco on its exterior and a roof of solid copper. It's not a reception-friendly place for an old radio freak like myself—but hey, some compromises are easy to make.
One compromise I wasn't willing to make was with unnecessarily proprietary audio, video and Internet-based services. I didn't want anything that put us inside some company's silo.
The same went for lighting. My wife rejected a variety of centrally controlled lighting “solutions”, because they all required dependencies on specialized professionals with exclusive relationships with manufacturers of specialized gear that could be operated only by specialists using old Windows laptops with serial ports that plugged in to central control units in the garage. Not to mention light switches with labels corresponding to moods and stuff. Plus, prices four times to X times higher than plain-old light switches that anybody can understand.
There are lots of ways you can go down the same expensive dead-end route with, say, home theater equipment or whole-house audio. I have a friend with a whole-house audio setup that nobody knows how to operate, including himself and the outfit that sold and installed it. Last summer, I asked for advice from Mark Cuban, the billionaire owner of the Dallas Mavericks and founder of HDnet, which supplies programming to high-definition TV customers. He told me it was a big mistake to build a proprietary whole-house audio system. He did that the first time around and regretted it. “Go open”, he said. “It's the only way.”
That is why I wrote that piece on the Linux Journal Web site.
In it, I explained that, for the last few houses, my open audio distribution system has been a simple FM radio hack. At the main sound source (usually the receiver at the middle of our home theater setup in the family room), I put a Ramsey FM-100 transmitter, which radiates on an otherwise unused FM channel. The power is only .25 watts, and the signal barely gets out past the yard, but it's plenty strong inside the house where receivers in other rooms pick up and play the signal off their FM tuners. Most of our receivers are ones we grabbed cheap at garage sales. They have analog dials, with simple knobs for volume and tuning, and they sound great through speakers that are just as good. In our nine-year-old son's room is a great old mid-1980s Technics receiver that puts about 50 watts per channel through a pair of original Advent loudspeakers. The receiver cost $5 US at one garage sale, and the speakers cost $10 US at another. Next to the receiver is a Technics turntable with a Shure phono cartridge that sounds better playing my old Deutche Grammaphone vinyl recordings of Beethoven's nine symphonies (the 1963 series, with Herbert von Karajan, purchased almost that long ago) than the CD player spinning the same recordings remastered in digital form.
Still, FM is not the best medium for hi-fi audio. What would be better, if anything, that isn't some kind of silo?
In my LJ Web site piece, I mentioned the Sonos system, which I had written up in a small feature in November 2005's Linux Journal. Sonos sells high-quality amplifiers called ZonePlayers that each drive pairs of speakers and connect to each other wirelessly. These connect to audio collections on PCs or network-attached storage (NAS) devices to line-in sources (such as satellite radio, cable or satellite TV, iPods or whatever) and radio streams from the Net itself. I also had seen Sonos at CES last year and liked what the system did. I also said it appeared to be a silo.
One reader of the Web piece was Alan Graham, a writer whose works include a book, The Best of the Blogs, for which I had contributed the forward a couple years back. Alan wrote to tell me that I had not only misjudged Sonos, but that I should avail myself of the company's proximity to my house. Somehow, I had missed the fact that Sonos was right here in Santa Barbara. In fact, it was only a few blocks away. Most important, they had built out the whole Sonos system on Linux, and might make a good story.
So, I went over to check the place out, talk with some of their Linux hackers and see what was up with the company.
I've been to a lot of startups. Usually they're in funky industrial quarters on the cheap side of the railroad tracks. Not Sonos. Instead, they're in one of the most attractive Spanish buildings in a Spanish town that's been doing Spanish since the 1700s. The digs are a mix of offices and cubicles, with a staff energy that's as upbeat and positive as any I've seen. Although they wouldn't give me financial specifics, they did say they've grown every month.
More important, everybody seemed engaged. “What Internet station do you like?” one guy asked. I told him WUNC in Chapel Hill. “Cool”, he said. “We'll add that to the selection.” When figuring the IP address of WUNC's stream proved a bit problematic, other geeks joined in and they surmounted the problem. I overheard “What can we do for you?” and “How can we help?” several times while touring the facility.
At the end of the tour, I sat down with Steve Holmgren, a principal engineer at the company and a UNIX/Linux hacker of long standing.
Turns out Sonos grew out of networking: “We asked, 'How do we bring basic technologies from the Internet, and from the Open Source world, into the home?'”, he said. “We started very early on looking at everything, including Microsoft's embedded technologies. Obviously there were costs there. Meanwhile, we had a lot of background in UNIX and Linux, and knew it was a lot more approachable.”
Also flexible—Steve continued:
One of the things that got us there was evaluations of microprocessors. With Linux, we could develop software independently of hardware. We could do development, and bring up all our services, long before the hardware was ready. In fact, we could architect the whole thing in the complete absence of hardware. We put together a simulator for our controller on X Windows, with a prototype handheld scroll wheel and everything else. We put in a Flash interpreter that runs on top of that, so we could do a nice graphical display. All of that was running way in advance of any hardware. Linux allowed us to do that.
This was also a relief. Steve continued, “I've been involved in so many projects where all you heard was 'We're waiting for the hardware.' There were all these serialized dependencies. Not the case here. We had a great deal of parallelism in development. We could get way downstream much earlier than we would have otherwise.”
As for the development itself, he said:
It's all C and C++ running on our own embedded Linux implementation. We did it all from the ground up. We started with Red Hat because that's what we knew best, but then we pulled in whatever we needed for our own purposes. We started developing on the 2.4 kernel, so we've stuck with that. We're an embedded implementation, constrained on memory and don't have big iron needs, so we're happy there. We write a lot of our own stuff. We have a loadable audio driver module that we wrote and pulled in, for example. In fact, we did development on a PC-based Linux box and cross-mounted that with a development system via NFS, booted the system dynamically across the Net, brought over the driver module and debugged it. We did that over and over again. Nice integration, booting up embedded boards, things like that.
The microprocessor they ended up using was the Hitachi SH. “We liked the floating point and the PCI interface that's built in to it”, he said. A fun coincidence—back around the turn of the 1990s, I worked with Hitachi Semiconductor on rolling out the SH in the US. (One rumor had it that the processor was named after Sonic the Hedgehog. Sega was a big Hitachi customer back in those days.)
“We're steeped in Linux here”, Steve said. “It's part of the infrastructure. We have it so tuned at this point that I couldn't imagine ever doing anything else. It's wide open. If we ever want to change hardware, we can do that easily. We're flexible that way. If another processor vendor comes along with better features and pricing, we have the ability to move.”
Linux and open source are also involved in the company's own central service offerings out to customers:
We have a network server that implements SOAP, is open source and publicly available on SourceForge. It's called Anacapa. We named it after Anacapa Street here in Santa Barbara, but later I found out that it's also a Chumash word that means “constantly changing”, which makes complete sense. We use it in our support infrastructure. We can come into the customer's system and gather statistics, do diagnostics and provide services. There are an enormous number of statistics that we can put to use—error logs and so on. All HTML- and XML-based.
I said, “So what you've got is a wireless home LAN that serves as an audio system and that can publish, by HTTP and XML, stats out to Sonos itself, to do diagnostics and stuff like that?”
“Yes”, he said. “And we use SOAP as a control architecture to run commands between the different nodes. It's a peer-to-peer level mesh network. So its stable and very reliable.”
“Is there one central unit that needs to be wired?” I asked.
“There is one that needs to be connected by Ethernet to the router. That's more for performance than anything else. Beyond that, they can all be wireless. You can have any combination of wired and wireless. You have fantastic audio quality, and you don't lose anything with N nodes. It's endlessly extensible.”
But still, I wasn't sold. For that, I needed to set up a couple of ZonePlayers in my own house and put them through the paces.
So I took advantage of their Introductory Bundle: two ZonePlayers and a Controller for $1,199 US. There's a 30-day money-back guarantee, “no questions asked”, they say. Two business days after my visit, the bundle showed up on my doorstep.
I hooked one up to the speakers in the family room, and the other to the speakers in the living room (which in this house are in opposite corners of a long L). Now, I needed to get both of them on the Net. For that, the back of each ZonePlayer has a four-port 10/100 switch. Each port has a light to indicate activity, which is handy. In our house (which we remodeled a couple years ago), every room has several RJ45 wall jacks connected by CAT-5e cabling to a patch panel in the wall of a bedroom closet upstairs. Each ZonePlayer came with an Ethernet cable, so I used one of these to connect the family-room player to a wall socket, then went upstairs, opened the wiring panel and patched the connection through to a hub connected to our Cox Business Internet cable modem. Then I followed directions that came with the gear and quickly realized we weren't getting out on the Net. A call to their 800-number got me immediately to David, a support guy working in Sonos' offices down the street (rather than somewhere in India or wherever companies put their outsourced tech support these days).
After a brief geek-to-geek conversation, I remembered Cox requires that I let them know the MAC address of everything new on the local network. This is easy with ZonePlayers, because the serial number on the back of each unit is also its MAC address. But I didn't want to make more calls, so I went upstairs and patched the ZonePlayer through the hub from our Cox High Speed Internet household service, which isn't so picky and has faster downstream speeds anyway (3Mb vs. 1.5Mb for the business, which is also more expensive, but that's another story). We were on.
I registered the service, and things began to roll. I got the other ZonePlayer on the wireless mesh, using only the controller, which looks like a wide-bodied white iPod. It features a scroll wheel, buttons for Zones, Music, back (|<<), forward (>>|), pause (||) and going up a level (one of those bent arrows that looks like a sideways U). There are also three soft buttons along the bottom of a large and vivid color display. The volume control is a +/– rocker switch, and you use the scroll wheel to choose which zones it's controlling. You can control the volume for any or all of the ZonePlayers, which you select with the scroll wheel. Each ZonePlayer also has its own mute and volume controls.
For music, you press the music button and navigate with the scroll wheel. The bull's-eye button makes your choices. Getting the hang of it is easy.
Each ZonePlayer comes with a CD that installs control software for Windows or OS X. In addition to providing a console for monitoring and controlling the system, it administrates the music library served over the system from the desktop.
When I observed the absence of a Linux version of the same software, I was transferred to Sean Sullivan in the company's Cambridge, Massachusetts office. Sean said he uses nothing but Linux at home (all Gentoo) and doesn't miss the desktopware. “I get along fine with just the handheld controller”, he said. “All my music is on a NAS box.” In fact, he recommends keeping music on a network-attached storage device in any case. “Your basic NAS is a Linux box running Samba”, he said. With the handheld controller (another Linux device), you simply enter the Samba address of the NAS, and there's your music. Sean is partial to Buffalo Tech products, by the way. He says “that's mostly what you see when you walk around the company.” He also said there was nothing other than market demand keeping the company from making Desktop Controller software for Linux. “It's just UPnP”, he said. UPnP stands for universal plug and play.
To test it out, I installed the Sonos Desktop Controller on an old OS X laptop that has a large pile of MP3s on it. In very little time, that same music was now on the handheld controller, ready to play. Given how lame that old box is, the performance was remarkable. The controller roughly replicated the functionality of an iPod. In fact, you might think of the Sonos system as a very flexible whole-house iPod, without Apple's proprietary silo.
Even though I have a large MP3 collection (mostly ripped from many shelves of CDs, plus an assortment of old vinyl albums), I'd usually rather listen to Internet radio. Veteran Linux Journal readers know I've been harping about Internet radio since the late 1990s. For all those years, I've wanted an Internet radio that's easy to tune and that can play through a good household sound system.
Well, now I have it. And I'm in love.
Sonos provides customers with a large assortment of stations, sorted by genre. More can be added through the desktop software, once you find the URL of the stream you want. I did, and promptly added a half-dozen favorites. You can also contact Sonos and ask them to add stations to the defaulted list. “We love it when people do that”, said a customer-support guy.
Each ZonePlayer also has a line-in input, through two RCA jacks, so you can play a CD player, an FM tuner, an MP3 player and anything else you want through it. I jacked in a new Sirius Satellite Radio tuner, and it worked perfectly.
ZonePlayers also have a pair of line-out jacks, along with a subwoofer jack as well. I eagerly hooked these up to my Ramsey FM transmitter to drive my legacy audio distribution system—and was met with my first and only disappointment with the Sonos system. It turns out that the line output is volume-controlled. So, if that ZonePlayer is turned down or muted, so is the line output. This means I can't drive the FM transmitter with it—or anything else I can imagine. After a series of phone calls and e-mail exchanges, I learned that fixed line output should be a selectable feature by the time you read this.
Meanwhile, I'm requesting it anyway, on the company forum. I'm also requesting a Linux version of the desktop software, plus the ability to add stations through the Controller. Given the openness and responsiveness of the Sonos staff, I'm optimistic about all those requests—plus lots of others I see when I cruise the forums' threads.
The most remarkable thing about the Sonos system is the wireless networking, which is robust beyond any of my expectations. A few months back, we experimented here at the house with Apple's AirTunes system, which sends audio from iTunes on a laptop through an Apple Airport Extreme Wi-Fi base station to an Apple Airport Express Wi-Fi base station, and out that through a stereo headphone jack to our family-room audio system. It failed. The signal dropped out constantly, and it was vulnerable to people walking around the room. None of the devices involved were more than 20 feet from each other. With the Sonos system, the two ZonePlayers are at opposite corners of the house. One is located alongside a Linksys Wi-Fi base station that can't even be picked up on a laptop at the other ZonePlayer location. Yet the music through the second ZonePlayer sounds beautiful, with no drop-outs at all. Internet radio, which sometimes has problems staying connected in iTunes, is rock solid. Last night, we were listening to jazz and classical stations from France, The Netherlands, Norway and North Carolina. Nothing dropped out. Nothing was degraded. And each station came up almost instantly when we tuned from one to the other.
What's more, the Sonos system gets along with all four of our household Wi-Fi stations, plus any number of laptops that come and go, plus our 2.4GHz Panasonic home PBX, which has a total of six stations, all working perilously close to the Wi-Fi band. Sonos tech-support guys told me Panasonic 2.4GHz stuff sometimes causes problems, but we have had none in our case.
I had thought at first that the Sonos was something of a silo, because it used the Wi-Fi band in a nonstandard, nonvisible way. But one of the technicians told me the purpose for that was neither lock-in nor secrecy: “We just don't want to interfere with anything else you've got going on.”
And they don't.
The Sonos gear isn't cheap. ZonePlayers run $499 US and controllers run $399 US. Two things help rationalize the purchases. One is that many features of both are software-upgradeable, so they're future-proofed to a degree that's become uncommon in home electronics, much of which is made to be tossed out in two or three years. The other is that they are very solid and well made. Each ZonePlayer is smaller than a shoebox and has the heft of a storage battery. When I toured Sonos' facilities, I was impressed by the quality and construction of the ZonePlayers I saw disassembled on desks and workbenches.
Audio performance is also terrific. The 50-watt per-channel output spec may seem underpowered, but these ZonePlayers seemed no weaker than the 60-watt Pioneer and the 100-watt Technics receivers they replaced at the two locations. And the sound seemed better to me in both cases.
The system will play MP3, AAC/MPEG-4 and WAV audio files. It won't play DRM'd files like the AAC variety sold by Apple on its Music Store or similarly crippled offerings from the Windows Media silo. (It would be nice to see OGG added to the list. I'll request that too.)
Of course, there are other choices in the same market category. Among the responses that came to my original request for help were several pointing to Slim Devices' SqueezeBox, a Linux-based player and controller that works with music sources on your PC (including Linux PCs). My old friend Andrew Leyden of PenguinRadio also pointed to his company's Solutions WebRadio. There are others as well. If you're in the market, I suggest kicking all tires.
Meanwhile, I'll be keeping my Sonos bundle.
Resources for this article: /article/8753.
Doc Searls is Senior Editor of Linux Journal.
Doc Searls is Senior Editor of Linux Journal
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Reply to comment | Linux Journal
5 hours 26 min ago
- Nice article, thanks for the
16 hours 7 min ago
- I once had a better way I
21 hours 53 min ago
- Not only you I too assumed
22 hours 10 min ago
- another very interesting
1 day 3 min ago
- Reply to comment | Linux Journal
1 day 1 hour ago
- Reply to comment | Linux Journal
1 day 8 hours ago
- Reply to comment | Linux Journal
1 day 9 hours ago
- Favorite (and easily brute-forced) pw's
1 day 10 hours ago
- Have you tried Boxen? It's a
1 day 16 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?