Using the Rio Receiver

Using the Rio Receiver (and other unimportant info)
Chris Uriarte, chrisjur@cju.com
Originally Published: November 22, 2001; Last Updated: January 5, 2001
This review was featured on Slashdot on November 23, 2001. View the article, comments and flames here.

[Update: January 2002: Since this article hit Slashdot, I've received a number of emails from some helpful people. I had the opportunity to chat with a member of the Rio development team that worked on the original product. It appears that SonicBlue is working hard to add new features to the client software and firmware. Two months after purchasing the Rio, I still love it and my friends are still jealous.]

What is it?
The RIO receiver is a small devices that allows you to play your digital MP3 and WMA music through any stereo system. It attaches to an Ethernet network or a HPNA (phone line) network, allowing it to access digital music files stored on a Windows PC. It's manufactured and sold by SonicBlue [http://www.sonicblue.com], the people who bought the Rio [http://www.riohome.com] line of digital music equipment from Diamond. The same device is re-branded and sold by Dell [http://www.dell.com] as the Dell Digital Audio Receiver The street price for the unit is about US$200. You can find out more about it at its website [http://www.riohome.com/products/receiver.htm]. Here's a picture for your viewing enjoyment:

(Picture Says: "Click me for a giant-sized view")

What are the tech specs?
Without going into the nitty gritty details, here's some tech specs on the unit:

Unit measures 9"x9"x3"; contains small LCD screen, a few buttons and a jog dial on the front.
74MHz ARM7 Cirrus processor
Runs a tiny version of Debian Linux
4MB of DRAM
512KB of flash memory
CS8900 based 10MB ethernet interface
Broadcom HPNA interface. HPNA is some ass-backwards networking setup that allows you to run data over your home phone lines - be afraid, be very afraid! [Update: December 2001: OK, I admit, I was too harsh on the HPNA. A lot of people have written me to say that the HPNA works just fine.]
One set of standard RCA audio output jacks
One set of standard speaker connectors

Why buy it?
The advantage of purchasing the unit is that it gives you access to your digital audio collection through any stereo in your house that's close enough to a phone line or ethernet port on your home network.

Why I bought it.
Let me set the stage by saying that I have over 500 CDs and that I am addicted to music. One day, I realized something important: my music collection was taking over my life. It was getting too large to handle and my fickle nature makes me want to listen to many different types of music in a relatively short period of time. CDs tend to get stale very quickly when they are in my CD player. After having, what alcoholics sometimes refer to as, "a moment of clarity", I realized that it was time to get my act together. I discovered that my car contained 70 CDs - it was a $30,000 CD holder that happened to also be able to get me back and forth to work. There were about 100 CDs laying around in my home office and about 30 in my office at work. There were numerous CDs stuck in changers and players and CD holder and travel pouches and attache bags and just about everywhere I could put them. I was out of control. My girlfriend was about to stage an intervention when I told her that I was going to buy a third CaseLogic car visor CD holder - which I somehow thought I could rig into place, despite the fact that my car, like most others, only has two sun visors. It was bad, and I needed help. One day, I had a vision - If I made my music collection digital, I could access it from anywhere - my stereo, my car (through a car MP3 player), on the road (through a portable MP3 player), at the office, etc. I really hated my trusty Sony CD 200-disc changer, which I know has swallowed a number of CDs that I've been looking for the last 5 years. I had a dream about being able to "dial up" my music - without having to know which slot it lived in or figuring whether it was even in my house at all. I thought the Rio Receiver could help me fill these dreams. (I know, It's sad. One day I'll seek professional help.)

Where to buy it.
When I was first searching for it (November 2001), the unit was somewhat difficult to find. There were only about five online retailers carrying it, and most were out of stock. I settled on the dependable, but expensive, Crutchfield [http://www.crutchfied.com], where I purchased it for $179. Note that I have seen street prices as low as $156. Check out CNET's price comparison service [http://shopper.cnet.com/] to try to hunt one down.

What do you get with it?
The box it's packaged in is roughly the size of a toaster over. Open it up and you'll find:

the Digital Audio Receiver itself
Home PNA adapter card - (Note: It appears that some models do no include the PNA adapter. That's good...avoid it at all costs)
Remote Control
2 "AA" batteries
one 6" RCA stereo patch cord
one 6'6" telephone cord (probably only included if you get the HPNA card)
one 12' 6" telephone cord (ditto)
one 6' 6" AC power cable
one CD containing the necessary server software installation and owner's manuals
lots of cardboard, styrofoam, plastic, foam and other things that kill the environment. Crutchfield is also sure to pack the receiver box in a larger box small enough to hold a child - however, the child would never survive after suffocating from the grotesque amount of styrofoam peanuts inside.

It comes with a "quick start" sheet, which is good enough to actually get it up and running pretty quickly. The full documentation is on the CD-ROM, or available on the Rio website in the Support section. However, the full documentation is scarce on juicy details, although worth a quick read.

Setting it Up
Assuming that you already have an Ethernet network in place, all you need to do is the following:

2. Plug the unit in. Hook up the RCA jacks to your stereo. Plug Ethernet cable in the back. Turn the unit on.

3. Select your artist/album/playlist from the LCD screen and start playing music.

The whole setup process literally took me less than 10 minutes, most of which was spent chasing runaway styrofoam peanuts across my hardwood floors.

What does the Windows Software Do?
Yes, you must - I repeat - you MUST use the Windows software for this thing to work (see notes on the Linux hack below, however). The software is not exactly what I would call "feature filled". The software has two purposes in life:

That's it. And you don't have options to play with those two either. It is truly as if SonicBlue had a meeting and said, "What is the absolute, minimal amount of work we can do to make this piece of software work?". It then appears that they took that list of minimums and cut it in half. It is barebones, to say the least.

Those who own other Rio products may be use to getting some type of CD ripping or digital file management software with players. This, however, doesn't include anything like that.

The Windows software, dubbed the "Audio Receiver Manager", doesn't actually allow you to manage anything. It does manage to discretely sit in your system tray and is loaded when you startup and log into windows. Since I always keep my main computer on and logged in, it's not a big deal to me, however, the audio manager will not start until you log into windows (i.e. enter your username password, if you get prompted for one). I'd like to see this made into a Windows NT/2000 service for the next release. [Update: November 25, 2001: Scott Alfter wrote me to tell me about FireDaemon [http://www.firedaemon.com], which essentially turns any Windows program into a WinNT/2000 service. I downloaded it and got it running in under a minute. It works great with the Rio Audio Receiver Manager and solves the problem I described above.]

Basically, you tell the software where on your system to look for MP3/WMA/M3U files. You have the ability to specify entire drives, which can be very slow, or individual folders. You must update the database every time you want to make new music available to your receiver. During the import process, the Audio Manager must stop playing music - apparently it has difficulty walking and chewing gum at the same time.

Here's some screenshots of the Windows program:

(Click for larger images)
A Note on Image 2 above: The Audio Manager shows that it imported about 1500 tracks and 120 playlists in 16 seconds. This particular import was run on a folder of MP3s that was already imported, so it ran rather quickly. When I first ran the import on this folder, it actually took close to 40 seconds to import all the tracks (not bad at all). However, this was done on a rather speedy Athlon 1.33Ghz with 768MB RAM and 7200 RPM drives. Your mileage may vary. The Rio documentation, for example, shows a screenshot of an import that was smaller, which took a considerably longer amount of time.

Things that particularly suck about the Windows-based Audio Receiver Manager software:

It is pretty much un-configurable. Choose your DHCP range and choose your folders to scan, that's it.
There's no sort of "preferences" available to save your settings, which would be nice. Even though I only search for MP3s under one directory (D:\MP3, for example), it always defaults to search the entire C: and D: drives. I then have to remove and re-select D:\MP3 EVERY TIME. This is maddening.
Somehow, SonicBlue thought it would be helpful to have this thing search your MusicMatch and RealJukebox playlists - I can certainly see the value to this feature. However, you don't have the ability to disable searching these programs and the internal track lists and playlists are imported from these programs every time you update your database. This causes duplicate track and artist names to appear on your Receiver. For example, if you tell the receiver to search D:\MP3 for your of your tracks and you have previously imported the track names into Real Jukebox, all your tracks will be duplicated when you bring them up on the Receiver's LCD. This is fine if you want to "manage" all your music from RealJukebox, but I don't. Even after removing the tracks and playlists from RealJukebox, there were still dupes....I finally just uninstalled RealJukebox (it's a piece of junk, anyway). If you use MusicMatch, it will only import your MusicMatch playlists, which can be handy at times - but it's all or nothing....if you create playlists in MusicMatch, they will ALL show up on the Receiver, as you don't have any choice to exclude specific playlists.
As mentioned before, the software sits in the system tray and is launched from your Startup folder. Therefore, if your machine reboots or you log out of Windows 2000/NT/XP, the Audio Manager software is not running - so no music for you.

Playing your Music From the Receiver
When it comes down to doing what it is meant to do, the Rio Receiver does a very good job. It's very easy to navigate through your music collection, even if you have a large number of tracks, artists and albums. I have close to 150 albums worth of digital music and I can easily find what I'm looking for in a few seconds.

Music selection is done using a simple jog-dial knob on the front of the unit. You have the ability to search for music by artist, album, song title, genre or m3U playlist. All this information is determined by the ID3 tags [http://www.id3.org] contained within your MP3 files - therefore, it's VERY important that all of your MP3 files are embedded with at least the artist, album and song title. (See my "Tips and Tricks" below for details on this). The Rio DOES NOT CARE about the organization of your directory structure - all it wants to know is the contents of your ID3 tags.

Overall Quality and Performance
Overall, the sound quality is very good. Of course, sound quality greatly depends on the bitrate used to encode your digital music files. I encode all my MP3s at 192 bits using LAME [http://www.mp3dev.org/mp3/] - the quality is excellent. The Receiver just takes a digital stream of the music files over the network and decodes it, so there is no loss in quality due to the network transfer or any weird types of streaming protocols. At 192bits, no one can tell that the music is sourced from am MP3 file.

The unit has a 10-second buffer, just in case there are any network slowdowns. I wanted to figure out just what it would take to make the thing stop or skip or do whatever it may do if the network gets really busy. So I wrote a simple Perl script to transfer a 200MB file between my Windows box and my Linux box over HTTP using 15 simultaneous threads (i.e. 15 downloads occuring at the same time). This is, of course, way more than what I normally see on my home LAN, which is usually just comprised of me and my girlfriend surfing the web (mostly me, of course). I should note that my home network uses a NetGear 10/100 Hub (not a switch) and a Linksys 10MB in the Living room - so the effective throughput will never exceed 10MB (not including protocol overhead). With 2 Skinny J's The Whammy playing in the background, I started the network torture test. Despite the fact that my Linux box's four-year-old hard drive protested, the Rio Receiver didn't skip a beat (no pun intended). So I think you can be pretty sure that this thing will work well, even in a busier network environment.

Did you say it runs Linux?
Yes, it runs Linux. Many people tend to get very aroused about this these days. I am a Linux advocate, as I like to advocate any technology that helps you work or play better, but I'm not a Linux zealot. But for the more curious, the unit has already been hacked, although it appears to be a bit more difficult to do than it should be. Jeff Mock has put together a wonderful collection of information [http://www.mock.com/receiver/] related to hacking the Receiver. Even though I was greatly tempted see what you can do with the thing, I figure I bought it to do what it does best - play music. I'm happy with its feature set and don't feel the need to crack it open. If this unit gets more popular and there are a number of good hacks available out there, you may see more people trying ot hack it.

What Operating Systems Does it Work With? (Do I have to use Windows?)
The Rio Audio Receiver Manager software officially supports Windows98, 98SE, 2000 and ME. Although not listed, I'm sure it also works on XP, as the application nothing more than simple HTTP and UDP server. [Update (November 25, 2001): My friend, Roy Tucker, confirms that the Audio Receiver Manager software runs on XP. So blame him when it blows up your PC.] It will not run on Windows95 or WindowsNT 4.0.

There are a few efforts underway to make the unit work with non-Windows servers. The first is a home-grown project put together by Jeff Mock [http://www.mock.com/receiver]. Jeff has done an excellent job at reverse engineering the Rio's protocols and has put together a number of scripts that allow you to use a Linux machine as the file server. At this time, his software does not support playlists, but after looking at the code and the protocols, it is probably an easy thing to add. Be aware, though, installation of Jeff's code is not a trivial task - you need to have knowledge about Linux, Apache and Perl and there's not a lot of "HOW-TO" documentation available (who has time to document, anyway?...especially for open-source projects that don't pay the bills?). It took me about 40 minutes, but I got Jeff's scripts running. Again, he did a great job with this.

Second, there's an open source project called Digital Audio Server [http://sourceforge.net/projects/das/], which I have not tried out. It looks as if it might be a bit more complete and simpler to use than Jeff's solution.

There's a third project called Jreceiver [http://sourceforge.net/projects/jreceiver/], which is open source servlet-based audio server built to support network-based MP3 players like the Rio. However, it appears to be quite immature at this time. It's completely servlet-based, but does not support Tomcat, which is a major drawback, in my opinion.

Are there competitors?
Yes, in fact there is one generally-available competitor that I am aware of: The Turtle Beach Audiotron [http://www.audiotron.net/audiotron.asp]. I like this particular product a lot. Had it not been for the Rio's attractive $150 street price, I probably would have bought the Audiotron. There are a few major differences in the way that these boxes operates. First, the Audiotron is a full-size (but thin) stereo rack component, so it can blend nicely into your existing system. Second, the Audiotron accesses music over a simple SMB share, so you can simply export a folder from your Windows or UNIX box and make it available to the Audiotron. There's no server-side software required. Third, you can actually READ the LCD display on the Audiotron from a distance greater than 10 inches. Forth, the Audiotron has a TOSLINK optical output, which is nice to have. Last, but not least, the Audiotron comes with a suite of useful software, including a web-based front-end. The street price for the Audiotron, however, is about double the price of the Rio. You can read Rob Malda's review of the Audiotron on Slashdot [http://slashdot.org/article.pl?sid=01/10/12/1423233].

Tips, Tricks and Things to Be Aware Of

Use ID3 Tags - as mentioned before, the Rio gets all it's track, artist and album info from the ID3 tags embedded in the MP3 file, so make sure you ID3 tag your MP3s. The easiest way to ID3 tag your MP3s is to do it when you rip them from the CD using a good ripping program with CDDB/FreeDB integration (Check out Audiograbber [http://www.audiograbber.com-us.net]). If have existing MP3s that are not tagged, MusicMatch [http://www.musicmatch.com] does a good tagging job for no cost. Musicmatch will also identify all the MP3s on your system that are not tagged.
Use RealJukebox or simple file system management - the Rio Audio Receiver Manager WILL import all tracks and playlists you have setup in RealJukebox and you don't have any say over it. Therefore, you should manage your MP3s through RealJukebox or not use RealJukebox at all. If you search for MP3s on your hard drives AND have a RealJukebox tracklist built, you will get duplicate track entries when you bootup the Rio. [Update, November 25, 2001: If you delete RealJukebox from your system, the playlists will not be removed in the un-install process. Therefore, you need to manually go into the RealJukebox directory (e.g. C:\Program Files\RealJukebox) and remove all the folders. Note that if you are running the Rio Audio Receiver Manager, you will get a sharing violation when you try to remove these folders, so shut the Rio software down first]
Listening to Full Albums - There's only one way to listen to full albums the way they were intended to be heard on the CD: create an m3u playlist for the album. If you simply choose "Albums" through the Rio controls, it will list out the unique album names on the system (without the artist name attached to it). If you choose an album, the Rio plays through tracks in the album in alphabetical order - not in the order they appear on the CD. The solution is to create an m3u playlist for each album and then access the album through the "Playlists" option on the Receiver. Again, a good CD ripping program should create these playlists for you when the rip is complete.
Album Playlists help if they include Artist Names - Some CD ripping programs will create m3u playlists and name the file after the album you just ripped. The Rio displays playlists according to their file system name. Therefore, if you don't have the artist name in the playlist file name, you may have a tough time identifying and finding the album playlist your are looking for. The solution is to name your playlists in some format like "Artist-Album.m3u". Sadly, my favorite software, Audiograbber, does not let you configure the file name format of the playlists. So I wrote a Perl script that goes through your MP3 directories and renames the playlists to "Artist-Album.m3u" format IF you organize your MP3's in the following fashion:
```
+/MP3-Root-Directory
	+/Artist-Name
		+/Album-Name
			/Track.mp3
			/Track.mp3
			/Track.mp3
			etc.
```
I think this is the typical way most people organize their MP3's, so the Perl script may be helpful. Also, since I think Playlists are so important, I wrote a Perl script that hunts out any album directories that DO NOT contain playlists and prints them out for you. (BTW, if you didn't know this already, you need to install Perl [http://www.cpan.org] on your machine for these to work).
The LCD Screen is Small - You need to be pretty close to the unit to read the LCD, so choosing tracks from a distance is impossible. This used to piss me off, but I figured that with the old way, I would have to dig out another CD anyway (and chances were that CD I was looking for was MIA).
Tiny Gaps Between Songs - the Rio inserts an every-so-tiny gap between tracks...so small you don't really notice it. I consider this a good thing. For live albums and albums with songs that continue onto the next track without a gap, everything sounds like it did on the CD...the Rio does an excellent job with this. I tested Jerry Seinfeld's I'm Telling You For the Last Time (a live comedy album), 311's Live album (a live concert album) and Rx Bandit's Progress (a traditional studio album where the first 5 tracks flow into the next track) - all of them sounded great. [Update: January 2002: A kind reader points out the the small gaps are actually encoded into the MP3 files and points to a discussion here regarding gapless playback]

Final Thoughts and Impressions
At $150 street price, this thing is a no-brainer. Despite some of my gripes, it does what its supposed to do and does it well. I highly recommend it. I no longer require a CD player in my den. Everything gets ripped to MP3 and then played on the Rio. If you already have a home network in place and a lot of digital music, it's pretty much just plug-and-play. I've already enjoyed using the Rio for the short time that I've had it and I'm sure that I will get much more enjoyment out of it in the future. Good job, SonicBlue.

For the tech weenies:

How does it work? (Warning: very useless technical information follows...you may want to stop here.)
Given my particular background, I was more interested in how the Receiver actually gets music from the central PC. After further analysis, I became convinced that the great Rube Goldberg was the chief architect of Rio. I thought the whole thing could have been made a lot simpler, especially compared with the file-sharing simplicity of the Turtle Beach Audiotron (see "Competitors" above).

So I set out to determine the protocols used between the Receiver and the Windows server. I figured that if I could reverse engineer these protocols, I could write my own server software to circumvent the lack of features in Rio version - including getting the server to run on Linux. So I started running Etherpeek sniffs of my network and began analyzing the traffic flow between the Receiver and my PC. I was about a half hour into it when I first discovered Jeff Mock's great "Hacking the Rio Receiver" page [http://www.mock.com/receiver]. Jeff did a far better job that I did in my first 30 minutes, so I used his notes to compare what I sniffed (btw, Jeff, your 100% right on...awesome work). The result of Jeff's sniffing efforts produced a set of scripts that allow you to run a Linux version of the server software (available for download on his site).

Basically, the protocol is simple, but there's a lot of little steps to actually get to the point where the music starts playing. Here's a quick overview:

When the box boots, it sends out a DHCP request ("please, someone give me an IP address"). The Rio Audio Manager software on the PC responds to DHCP requests only for the RIO. This is based totally on MAC address, as I was able to send a spoofed DHCP request using the Rio's MAC from my Linux box. FYI, on the Windows side, I always limit the DHCP IP scope to exactly 1 address, which essentially gives the Rio a static IP. [Update: January 2002: Rio's developers have told me that there the software isn't looking for a MAC address, but a magic cookie contained in the Rio's DHCP request packets. I was able to get a response from the Audio Manager software only after completely capturing and replaying the Rio DHCP request from my Linux box. However, a DHCP request MAC src spoof from my Linux box did not work, which supports this fact.] Jeff relies on the OS to do the DHCP stuff - not his server software. You can, however, configure dhcpd to always dish out the same IP to a single MAC address, if you so desire.
After the Receiver is happy with it's IP address, it sends out an SSDP request on UDP 21075 ("someone please tell me where my server is") with the request string "^upnp:uuid:1D274DB0-F053-11d3-BF72-0050DA689B2F\n{Source MAC Address}\n". The Audio Manager responds with the IP address and port of the Windows server. It tends to use TCP Port 12078 on the server side. It actually sends back an URL to an .xml file (http://serverip:12768/descriptor.xml)...the important part is the port 12768, which will be used as the status port between the receiver and server.
The receiver actually does an NFS mount of /tftpboot on the server and grabs a basic Linux file system - sort of like an XTerm. It then reboots a second time, this time bootstrapping with the downloaded kernel. Jeff points out something interesting that I initially missed: the Receiver does an NFS mount of /tftpboot - it does NOT use TFTP to download the boot image from /tftpboot, as you would normally see with diskless clients.
When you first scroll through a list - such as "Artists", the box issues a HTTP query to the app port specified in the SDDP response that looks something like: "GET /query?artist=". The server responds with an HTTP response with a standard HTTP 200 header, Content-type, Content-length, etc. a a response string that looks like "ArtistA.1=61,0,0:ArtistB.1=32,0,0......etc." You can start to see that the software assigns a unique index number to each item in the list, starting with 1, assigned in alphabetical order. Once you select an artist, for example, it will then make a subsequent query for the tracks associated with that artist ("http://10.0.0.25:12078/results?_extended=1&artist=Artist" ). The server returns a similar list of tracks, each also having a unique track ID number. Once a track is selected, using its unique ID number, the Receiver asks for the tags associated with the mp3 file ("http://10.0.0.25:12078/tags/240", for example).
From that point on, it's time to actually play the music. This accomplished by streaming the data over HTTP, gracefully shooting a flow of TCP PSH's and ACK's across your network. The receiver requests the unique track id over HTTP a la http://10.0.0.25:12078/content/240.
While alive and active, the Receiver and the server software start to miss each other and send UDP status packets out to each other about every five seconds. Basically, the server says "State? (What's going down?)" and the receiver replies with it's current state, which includes its MAC address, the current song it's playing and an associated timecode.
It should be noted that once you sniff the format of these queries, you can simply just insert them into any old web browser to see the results the server sends back. Type in "http://10.0.0.25:12078/query?artist=", for example, and you'll get a list of all the artists in the database. Doing something like "http://10.0.0.25:12078/query?artist=c" returns all artists starting with C - this might be useful in building some type of music search engine or something. Doing something like "http://10.0.0.25:12078/results?_extended=1&artist=Ash" will return all songs associated with the artist Ash. To see all playlists, it sends "http://10.0.0.25:12078/content/100?_extended=1" and to view a specific playlist, it sends "http://10.0.0.25:12078/content/5e90?_extended=1", where 5e90 represents the unique playlist ID it was sent when it queried all the playlists. You get the drift....this isn't exactly rocket science. Given this simple protocol, you can easily write a browser-based frontend to the Windows-based Audio manager software.

I figured that if I wanted to write a web-based front-end for the Audio Manager software, I would need to figure out which port the server is running on. So I created a trivial perl script that mimics the Receiver, sending out a direct SSDP query to the Windows server, which is happy to return the all-important port number that the server software happens to be running on. Once you have that port, you can issue any of the HTTP queries above via a regular web browser or with any piece of code you may just create. Interesting note: by sending out the SSDP request from my Linux box, the Linux box now shows up as a "New Audio Receiver" in the Audio Receiver Software. This causes the server software to send my Linux box a UDP "status" query every five seconds (too bad my Linux box isn't answering).

Lots more that can be done with this...if you have the time and can think up a good use for it.

As a side not, if you're looking for a front-end to your MP3 collection and you're using Apache, take a look at Lincoln Steins's Apache::MP3 [http://www.modperl.com/Songs/], for use with mod_perl. I use it and love it. It gets me access to my entire music collection anywhere that I have an Internet connection.