Setup and inspired design choices
Setup a cinch
On unpacking the system I charged the controller in its cradle. The next day, I hooked the ZP100 up to a pair of 'olden but golden' Celestion 3 bookshelf speakers that I still had lying around. I then connected one of the ZP100's Ethernet ports to one of the ports on my wireless router, installed the software on my laptop and powered everything up. Note: Laptop interface software was optional. The system immediately and flawlessly performed a software upgrade and I was able to assign a zone name (basement office) via the computer's desktop controller. On powering on the controller it immediately found the office ZP100 and I had full control of my system's music archives, as well as Rhapsody and Sirius radio and Napster files. The 30-day trial connections worked without a hitch and within seconds I was listening to U2 and Pavarotti singing Miss Sarajevo. Frankly, I was more than pleasantly surprised at not only the simplicity of setup but also the sound quality of the ZP100. It was clear, crisp and powerful and no detectable distortion or latency-induced artifacts.
The next step was to hook up the ZP80 to my main audio system upstairs. It seemed to connect OK but then lost the connection. Turns out there was an issue with associating that was likely due to a previous connection to another network. In any case, it resolved itself and I was quickly controlling both the main system and my basement office ZP100 using the Sonos controller. Any combination of audio streaming was flawlessly reproduced: from a single stream to multiple streams from different Internet and local-storage sources. All worked without a hitch.
Key design choices
At the heart of the Sonos system is a consistent commitment to simplicity. At the time of its introduction, systems such as Audiotron (Turtle Beach) and SlimDevices were already available, but were wired or were simply gateways and in Sonos's mind didn't adequately resolve the problem of getting audio from a computer to the bedroom. In addition, and more symbolic of the sea-change underway in audio reproduction, "What if I didn't even have a stereo and didn't want a PC on all the time?" The designers focused on the software interface and leveraging software to hide the technical complexity behind the audio distribution mechanism.
(Click on image to enlarge)
Fig.2: Rear view of system showing Ethernet, speaker, analog (RCA) and digital connections.
To that end, the team made four critical design decisions early on. The first was to go with a software-upgradable approach that gives the controller a 5-year expected lifespan and the ZP100 10 years. "We can innovate on the software," said Schulert. "Since first shipping, we've had eight updates so far all for new features, not bug fixes. All were done easily just reflash and reboot."
The second critical decision was to use a proprietary mesh network, SonosNet, versus working with existing 802.11-based access points. According to Schulert, the downside to their decision for the mesh is requiring that at least one unit be wired to the home network (something they've since mitigated with the ZoneBridge). "But this is more than outweighed by the ease of setup, the increased range of the mesh and some other more minor changes that increase the robustness of the network." One example of how they could make the network more robust was the ability to use two antennas and thereby choose any of four combinations for devices to talk to each other. More on that later, when we look at the difficulties of working with wireless. For now, it's important to note that SonosNet is a secure network that uses 128-bit AES encryption and runs on 2.45-GHz 802.11b/g-based radios.
Thirdly, the team decided to use file sharing to access music, versus requiring a server process on the PC. "Having a server would let us leverage the processing power of the PC," said Schulert. "However, we didn't like the complexity of setup and requiring that the server always be running. We also wanted to work with network attached storage (NAS) devices, where we couldn't run a server."
Finally, the team decided to develop a thick client versus building a web-based interface that could run in a browser on both Windows and MacOS. The thinking was user centric: "The end-user experience was more important than any time we could save," said Schulert. "With thick clients we can have the appropriate look and feel for each platform."