Abstract: In the last few years, MP3 players have made it ...



MP3 Radio

The Truly Mobile & Wireless Music Solution

Michael Backman, Richard Bannon

Department of Computer Science and Engineering

University of Washington, Seattle, WA

{mbackman, rbannon}@cs.washington.edu

Abstract

In the last few years, MP3 players have made it possible to take your whole music collection with you anywhere. Despite this convenience, you are still limited to listening to your music through headphones. MP3 Radio makes use of Intel’s Personal Server and newly developed Slappy card, along with a Bluetooth enabled cell phone, allowing you to listen to your music on any stereo with an FM tuner. MP3 Radio is designed to be a ubiquitous music device that is always on. The device is, conveniently, controlled with a cell phone, which most everyone already carries with them everywhere. The cell phone interface provides lets the user browse through their music and create play lists, similar to a typical MP3 player. Our implementation does provide the convenience of an MP3 player as well as the added benefit of being able to listen to it on a regular stereo anywhere. The main goals of MP3 Radio were portability and ease of use. As you will see in this paper, we were able to achieve both of these goals. This project also shows the practicality of Bluetooth enabled cell phones in controlling other Bluetooth devices. Finally, we see that a device such as Intel’s Personal Server can be a powerful mobile device when used in conjunction with other mobile devices.

1. Introduction

Digital music in the form of MP3 files has exploded in popularity the last few years. Today it is possible to store your whole music collection on an MP3 player the size of a deck of cards and take it with you anywhere. MP3 players are still limited in one facet: you are limited to listening to your music through headphones. You can buy special cables which make it possible to connect an MP3 player to a regular stereo. This helps to solve the headphone problem, although it is a limited solution. You still have to pack around cables with you if you want to listen to your MP3 music on different stereos. Also, many of these wire kits don’t allow you to connect your MP3 player to a car stereo. We are living in the wireless age and for that reason, a solution should exist to this problem which doesn’t involve wires and that works on any stereo. This is exactly what we had in mind in designing MP3 Radio. Before we go into what MP3 Radio is, we will give a typical scenario describing how someone might use it.

Joe is a typical MP3 radio user. After he purchases the kit, he loads his entire collection of music onto the MP3 radio server using a standard 802.11 wireless networking connection. Joe then installs the MP3 radio client software onto his Bluetooth enabled cell phone. Once he finishes these two tasks, he is ready to begin using his MP3 Radio. He opens the MP3 Radio application on his phone. The phone automatically searches for other Bluetooth devices within range of his phone. The MP3 Radio server shows up in a selection dialog along with his laptop, which is also within range. Next, Joe selects the MP3 Radio device and a dialog which says, “Connecting…” pops up momentarily. The MP3 Radio client application starts in the “Browse” view and Joe can see that the application is receiving details of his music application from the MP3 Radio server. After a few seconds, an alphabetical list of, first folders, then music files is displayed on the phone. He can scroll down the list and using the up and down key on the phone. When Joe hits enter on a folder, the phone application displays the contents of that folder. Joe also sees that the “Option” key has a number of commands in it which allow him to add songs to his current play list and play songs directly. Joe spends some time creating a play list of the songs that he wants to listen to. He then navigates to the “Playlist” view and sees that he can save his current play list and load play lists that are already saved. Joe is ready to listen to music on his MP3 Radio.

The first thing Joe does is plugs his headphones into the MP3 Radio server. Joe switches the MP3 radio application to the “Player” view. He sees that from within this view he can control the playback of his music. He chooses the “Shuffle” command and then hits “Play.” His headphones come to life, playing one of his favorite songs. After playing around a little, Joe is convinced that his MP3 Radio has all of the functionality of his old MP3 player. Joe is pleased that he isn’t loosing any functionality with his new music player. Now it’s time to test out the feature which persuaded him to buy MP3 Radio: broadcasting his music over FM radio.

Joe unplugs his headphones and places the MP3 Radio server in his briefcase. Next, he walks into his living room and turns his stereo on and dials in 88.7 MHz on the FM tuner. Sure enough, the same song that he was just listening to with his headphones comes to life on his home stereo. It’s almost time for Joe to head off to work so Joe decides to make a new play list of his favorite driving music.

When Joe gets into his car, he turns on the stereo and tunes into 88.7 MHz. Before he pulls out of his driveway, he pulls out his phone and opens up the MP3 Radio application. He navigates to the “Playlist” view, loads his driving play list and then goes to the “Player” view and hits play. The car stereo starts playing his driving music. The music sounds particularly good in his car because he has a several-thousand dollar car stereo. When Joe gets to work, he just leaves his MP3 Radio going. In his office, Joe turns on his little table-top stereo and tunes in the correct FM station. Again, the stereo comes to life with his driving music.

Joe is really pleased with his new MP3 Radio. He can take his music with him and listen to it anywhere without having to pack around a bunch of cables. He usually leaves his MP3 server in his brief case and just forgets about it. He only needs to charge the device once every two or three days. Joe especially likes the cell phone control. He is used to having his cell phone with him and he is happy that he doesn’t have to carry a bulky MP3 player on his person to listen to his music anywhere.

MP3 radio uses three radio protocols to achieve its completely wireless functionality. The first is used to transfer music files to the MP3 Radio server and operates with a standard Wi-Fi radio. The second radio allows the client application running on the cell phone to communicate with the server application running on the MP3 Radio server. This radio uses the Bluetooth protocol. Lastly, the music is broadcast with an FM radio so that any stereo equipped with an FM radio can tune in and listen.

The most challenging aspect of the design of MP3 Radio was implementing the communication between the server and the client using the Bluetooth protocol stack. The MP3 Radio server runs Linux for an operating system and the phone application is designed to run on cell phones running Symbian OS. Much of the difficulty in implementing the Bluetooth communication was introduced because the two devices are running different operating systems.

Another challenge was simply designing applications using the Nokia Series 60 SDK, which are the development tools that are required to write applications for the Symbian cell phone. The Nokia Series 60 SDK is designed to plug into a third party development environment. The SDK is compatible with several common development environments including: Visual Studio, Borland C++Builder and Metrowerks CodeWarrior. Initially, the only development environment that we could get to correctly compile a C++ program into a Symbian Installation System (SIS) file, which is the type of file that applications are archived into for installation on the Symbian OS phone, was Borland C++BuilderX. Borland’s development environment was great except that the compiler gave horrendously vague error messages, which made development nearly impossible except in extremely small steps. After struggling with this long enough, we decided to try to get the SDK to plug into a different development environment. Eventually, we were able to get the SDK working semi-correctly with Metrowerks CodeWarrior development environment. We still had to rely on Borlands C++BuilderX to actually build the (SIS) file. CodeWarrior provided us with much more descriptive error messages so we were able to make much better progress in designing the client application for the cell phone.

3. Related Work

Mp3 players have become popular in the last years. Units are getting smaller and cheaper and song storage is growing. These players, such as the extremely successful iPod, are focused around portability, taking the market from older portable media players such as the CD, minidisk, and cassette.

Mp3 Radio expands on this idea by introducing remote access and broadcasting to the portable music market. The other players that have come out all require the unit to be listened to on headphones or by plugging into some other system. The controls are all still on the unit since it is designed to be used on the person. Mp3 Radio allows the user to leave the unit by any FM receiver, or even keep it in a pocket. There are no wires needed to connect to the receiver and no need to control playback with buttons on the unit. All controls are done with a cell phone.

There is one popular project called Bemused [1] that is very similar to ours. Bemused is an open source project that was created, just as ours, to control a music collection from a cell phone over Bluetooth. They are based off of the series 60 phone models running Symbian OS. The difference is on the server end. Bemused was written to interface with everyday PCs, controlling popular music playback programs such as Winamp [2] or Windows Media Player. [3] Mp3 Radio uses Intel’s Personal Server, which doesn’t have the functionality of a regular PC. The biggest problem is that it has no floating point math support, which most Mp3 decoders use. A fixed point solution had to be found. The Bemused server is also written to be usable on many platforms, while Mp3 Radio needs only to be targeted to the Personal Server.

Bemused, while feature rich and compatible, was too much for an application such as ours. What we needed was something that would run fast and not carry the extra weight of features and overhead that came with Bemused. The floating point decoder alone was enough to put the Bemused project out of our reach, although it maintained to be a large inspiration for our project.

The Bemused user interface is almost identical to the popular Winamp media player. The graphical skins that can be loaded into Bemused are basically ports from Winamp skins. Mp3 Radio currently has no such fancy interface, only a simple list driven one much more like the iPod.

The Mp3 Radio Server was built from scratch. Madplay was chosen to be the Mp3 decoder, and integrated into the application. All we needed to do was receive messages from the phone and process them accordingly. No large overhead was needed, just a simple message handler and the decoder. The complexity of Bemused just wasn’t necessary.

4. Approach

The Mp3 Radio project was developed in three large chunks. The user interface had to be designed on the Nokia phone and created to communicate with the personal server. Secondly, the Bluetooth connection itself had to be implemented and data streamed across. Thirdly, the personal server had handle Mp3 playback which was controlled via the messages received on Bluetooth.

The first part we created was the Mp3 aspect. The Slappy audio card hooked up to the personal server could handle the sound output and FM broadcast, but it needed .wav files to do so. An Mp3 decoder was needed to convert files from .mp3 to .wav. We looked for compatible decoders, but most decoders out there run on floating point algorithms. Unfortunately, our personal server has no floating point support, so a fixed point decoder was needed. After much searching, we found the perfect decoder.

Madplay is a command line based Mp3 player used on UNIX systems. It uses fixed point algorithms and we could modify it to our own design because the project is open source. The next step was to integrate Bluetooth to the decoder. We first created a separate Bluetooth communication program and verified its operation, and then put the two together. We replaced Madplay’s keyboard input with the Bluetooth message pump. Messages coming from the phone would now simply emulate the regular keyboard commands of Madplay.

When this was done, the Bluetooth data pipe was created. Bluetooth was chosen as a medium mostly because that is what is readily available on cell phones. However, Bluetooth was also designed for close proximity wireless networking, which is exactly what we needed.

Most of our time on this part of the project was spent learning how to use the Bluetooth protocol stack. Once we got things running, it was simply a matter of deciding on messages to be sent across and integrating with the phone and decoder.

Finally, we tackled the phone user interface. The phone we chose to use was the Nokia 6600. Our main requirement for the phone was that it had a Bluetooth interface. The 6600 was chosen because there were others here who had already done some development work with the phone so we would have someone to talk to if we had any problems.

The user interface design was modeled loosely after the iPod interface. A basic phone application was created to handle the device discovery and connection. Then a list of the usual playback commands are implemented to list songs, play, stop, or skip to the next or previous song. When a command is selected, a message is sent across the Bluetooth connection to the server.

Putting the three pieces together, we have a phone interface which efficiently talks to the personal server and has control over all basic music playback functions.

5. Implementation

Our largest obstacle in the project was Bluetooth. The protocol stack is very complex and figuring out how it all worked was quite a task. Dealing with connecting Bluetooth across two different operating systems only made matters worse. The personal server runs Linux, which handles Bluetooth fairly well once things get going. The phone was much more complicated.

[Richard, check out what I’m saying here…]

The Symbian OS required many more new classes and libraries to get Bluetooth working. The poor development environments made this task even harder with vague error messages and uninformative warnings. We eventually switched the phone code over to C++ just because we weren’t getting anywhere with a Java implementation and the development environment was a bit better. There weren’t really any tradeoffs to this decision, except a minor setback in progress, but that was quickly made up in the more efficient work we could do with C++. The phone, however, continues to plague us with problems whenever trying to develop something on it.

The personal server was also a large source of headaches. Connecting applications over Bluetooth worked every 3rd or 4th time we would try, or the server would randomly lose power, or reset. Our programs connect via Bluetooth just fine to other systems, so we believe the Bluetooth hardware on the server itself may be a bit buggy. These problems with the server severely slowed development progress throughout the project.

6. Evaluation

We evaluated the Mp3 radio in 3 categories: program robustness and stability, usability, and music quality.

We wanted the system to run smoothly. The server shouldn’t crash, the phone shouldn’t get hung up on its programming, and messages should stream between the two without unrecoverable loss or large delay. Mp3 Radio passed in most of this area. The message transport was flawless. To this day we have never lost a packet or gotten corrupt data that we have noticed. The Bluetooth protocols do a good job of getting data across, and fast too. Everything going through the pipe does so without noticeable latency. The phone did pretty well. No hang-ups or crashes have happened, although if the connection attempts fail, the phone will block out Bluetooth for a time while it fixes itself internally. If this happens, Bluetooth can be turned off on the phone and then switched back on to clear things up faster. However, while the program is running, everything goes very smoothly. Lastly is the personal server. Nothing about our programming has been causing problems, but the server itself is a bit stubborn. Random resets or power failures, and Bluetooth connectivity issues have constantly been a bother.

The second category we aimed for was usability. Does the player work well for what it was designed? Like the scenario in the introduction above, can you just throw the server in a briefcase and tune any radio around you to the right frequency to hear your music? The answer is yes. Our player passed with flying colors. Getting music to and from your player requires some more wired interfacing right now, but all music playback is completely mobile and wireless. Mp3 Radio passes the usability test.

The last category was music quality. How good is the sound that comes from the player? The answer is about what you would expect from an FM broadcast. The signal is good and clear if your server is near the radio, but once you go about 20 feet away, the signal begins to die down. That is the nature of radio broadcast, but for what it would be used for, the 20 radius is acceptable. On a related note, plugging headphones into the server works perfectly, although not within our project goals.

7. Conclusion and Future Work

The next thing this project needs is features. Our Mp3 Radio project only implements the minimal functions of a music player such as play, stop, next, and previous. Other players have things like fast forward, reverse, much more playlist control, or current song information. Much of this is supported in some way or another by Madplay; it would just be a matter of extending the project. Unfortunately, we didn’t have the time to do that.

Seeing the song play time displayed on the phone, along with the bit rate and other common Mp3 header information, would be a definite plus, and should be one of the first things to improve on the phone’s interface. Real time song information would mean sending constant updates to the phone, which may or may not affect the efficiency of the player. However, it is likely that the extra messages will not be too much of a burden, and some packet loss would definitely be acceptable since the data could easily be interpolated.

As far as extending playlist control, it would be nice to have full control over playlists. Using the phone, a user should be able to create new lists, load saved ones, and modify them on the fly. Currently,

[what CAN we do?]

Another feature of our project that could be done in the future is a file transfer system. Currently, there is no way to add or remove music from the compact flash except by removing the memory card and reading it on some other device. We need some sort of front end for the users to access the files with.

There are two routes to take on this, either a network approach or a web approach. A front end could be built that would create an SSH session to the personal server via its wireless connection, or even use FTP protocols to transfer files in and out. This approach would be efficient and secure, but it is downfall is portability. The goal of Mp3 Radio is portability. Taking your music anywhere means a user shouldn’t be confined to a single computer with installed software to transfer files.

A better approach is a web solution. The personal server runs an Apache web server, so why not take advantage of that? A web application could be created that would let you upload and manage files from any internet connection.

Another thing to consider would be a peer to peer connection. Perhaps users could exchange files directly from personal server to personal server. This introduces more security issues and would be a whole other project, but would be an interesting thing to tackle.

Something we could have done better if we did the project over again, would be to learn Symbian. A guide to programming in Symbian would have been a great thing to have, but we learned it all the hard way, and spent many frustrating hours not getting anywhere. Similarly, another valuable lesson can be learned here. Start early.

8. Acknowledgements

A warm thanks to Trevor Pering from Intel Research, who has been invaluable in helping with everything concerning the personal server.

Thank you to Don Patterson and Nik Livic for help figuring out how to program to the Nokia phone.

9. References

[1] Bemused.

[2] Winamp.

[3] Windows Media Player.

10. Appendices

10.1 – Personal Server Codebase

The code base for Mp3 radio came from the Madplay source. We took the Madplay player and added the necessary code to it to support Bluetooth connections and handle any new messages and functions we needed. The three files modified from the Madplay directory are the following:

▪ madplay.c – The Madplay entry point. Modified to open and close Bluetooth connections before and after running the main player.

▪ player.c – The bulk of music playback. Modified to support Bluetooth input instead of keyboard input to control playback as well as where all of our new functions to handle playlists on the fly and any other things we needed Madplay to do.

▪ player.h – Extended the player struct to include some Bluetooth and current directory information.

The code can be compiled simply by running “make”. However, strange things have happened when “make clean” is not run before recompiling the player. It is recommended to run “make clean” before each build.

10.2 – Running the Mp3 Radio Server

Making the program will produce the executable “madplay”. Once this file is moved to the personal server the following command is needed to run the application:

> ./madplay –r /mnt/cf1/Music/*.mp3

-r is a repeat flag. This will cause the playlist to loop when it reaches its end instead of closing the player.

The directory is the path to the compact flash card which contains the music in a directory called Music.

The player is instructed to play all files in that directory (*.mp3) by default. However, the player ideally will start up and automatically wait for a playlist to come from the phone before playing any songs.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download