Jukebox

From ProgSoc Wiki

Jump to: navigation, search

Contents

Rationale

What kind of club room has no music?

Furthermore, what kind of group music player forces people to be glued to the one machine?

Objectives

  • Provide good-quality sound to the ProgSoc room, playing music.
  • Remove the potential for remote abuse by mandating physical interaction (IE, requiring the pressing of a button (Dead Man Switch).
  • Allow users to select songs via an net-based interface.
  • Improve the atmosphere of the room during Thursday meetings.

Design

Designs for jukebox

There will be 4 major modules:

  • The Jukebox (Music Player)
  • The Database
  • The Net Interface
  • The Hardware Interface

Status

The project is now complete! I will upload all the source code when I get around to it!

RasPi:

  • Firmware on alsa updated to avoid popping
  • Oracle JDK 8 installed and running
  • Tomcat running

Software

  • Net Interface complete (jableader)
  • Jukebox complete (jableader)
  • Database complete (jableader)
  • Hardware interface finished, yet not complete [See note/bugs] (jableader)
  • Admin page complete

Hardware

  • Case
  • 2x Green Arcade buttons, Skip and Pause/Play
  • Dead man switch not activated

Case

  • Black box, with LEDs and Arcade style buttons

Notes / Bugs

  • Whilst the code was designed with the Dead man switch in mind (the skeleton's there), we determined it was not really necessary and would be more of a hinderance.
  • A known issue is when the jukebox is freshly started, then you press play on the hardware before pressing play on the net, the machine will be buggered and you have to restart.
  • There is an 'admin' page, where you can change the volume (now redundant), refresh the database (to load any new tracks) and reboot the jukebox entirely
  • To add tracks copy them to /home/music on niflehelm, then go to the admin page and refresh the database. The refresh will take awhile

Photos

Prosoc members working on the Jukebox project

See the facebook page for heaps more photos: http://www.facebook.com/media/set/?set=a.486606514744689.1073741829.151901931548484&type=1&l=2fb9f9d0a6


Retrospect

In all projects there should be some retrospect to the project, otherwise what have we learned?

  • JSP is brilliant. Efficient and very simple to use. No regrets on choice of language or library.
  • In hindsight, I found the liberal use of the singleton approach to be slightly cumbersome when working within the pure java code, however I found it vital in the jsp (much to my dismay). If I were to recreate the program I would attempt a dependency injection approach
  • I would probably redesign the interface to use websockets and fallback on an AJAX style.
  • A smarter approach to config and whatnots would be to avoid relative paths and just stick stuff in /etc like everyone else
  • Whilst I liked my abstraction and design in the hardware interface, I feel it could have been pulled off a little better.
  • If I was to re-do the system, I would probably move Database.Tracks to be an interface, and then have a private class in Database that implements it, This solves alot of my issues with that design.
  • Better logging. Little did I know Tomcat actually hides all my System.err and System.out logs which made the final debugging stage a pain in the ass
Personal tools