This project started life as a demonstrator for Rococo's JSR82 implementation for PalmOS, whereby a universal remote control program would be located via Bluetooth discovery and downloaded into a Palm to control a music server. (JSR82 defines the Java APIs for Bluetooth.)
The entities in its environment with which the player interacts are:
Elements in this diagram, apart from the webapp and server, which were developed by me are:
When the autotag script is run later (it is CPU-intensive), it:
The client supports the standard operations of play, queue, pause, skip, pan, change volume, etc. In addition, during playback it can display current progress and the cover artwork of the current track, or the position in the current playlist. See the screenshots below.
![]() |
![]() |
![]() |
![]() |
The server supports multiple clients and propagates state changes initiated by one to all of them. This allows, for instance, a TV-out signal to display the same information as the remote, presenting interesting possibilities for argument over choice of music.
A MIDP client is planned, to allow the server to be controlled by a JSR82-enabled phone, e.g., the Nokia 6600.
javax.sound.sampled
. The Service Provider Interface is
Javazoom's MP3SPI (or VorbisSPI)
and decoding is by its JLayer decoder.
Information on the currently playing track is displayed on an LCD screen (currently a Palm V running PalmORB) via LCDProc.
When a track has been played, audioscrobbler is notified of the fact, via a custom client interface, jscrobbler.
Hibernate controls access to the metadata generated by the player which is stored in the MySQL database. This currently comprises four tables which record: playlists, individual tracks, a cross-table mapping tracks to playlists, and a list of tracks which have been played but not submitted to audioscrobbler.
Spring abstracts the Hibernate O/R mapping and provides overall application configuration via dependency injection. (Retrofitting Spring to this application was remarkably easy: the bulk of the work was done in less than a day.)
While the architecture of the server has necessarily evolved, due to the time constraints on this project, it is moving towards an information bus down which events are propagated and whose observers are either local (e.g., the LCD display driver) or remote (the remote control). This is facilitated by the IoC container.
The most pressing current need is for a comprehensive testsuite in order to preserve developer-sanity. (The shortness of time available for this project does not allow sufficiently-thorough manual testing after each modification.)
The technology used by the webapp is fairly standard for a J2EE front-end: Struts is used for the view and controller parts, and Tomcat as the servlet container. Some use is made of the Commons Beanutils API, because it was already available from Hibernate.
Other, system-management, concerns are addressed by Webmin.