• The Hardware

  The hardware I chose to use was rather limited in performance, which I think illustrates the efficiency of the software and solution which I designed. Components were as follows:

  • CPU: Pentium II 300Mhz
  • RAM: 384Mb SDRAM
  • Motherboard: Intel i440BX-based
  • Video: S3 Virge DX/3D
  • Storage: 4Gb, 5400RPM ATA HDD
  • Sound: Creative Sound Blaster Live! 5.1

  Obviously, I chose the software based on the known limitations of this hardware. Luckily I had a spare SoundBlaster Live! card, because I don’t think the system would’ve been able to reliably handle the music playback and the overheads of the user interface without it. Of course, whatever hardware you plan on using will probably be much faster. I really did pull this box right out of the stone age.

• The Operating System

  The operating system I chose in order to optimise performance was of course my favourite Linux operating system: Arch Linux. With the kernel, modules and all packages being i686-optimized, it was a good starting point for a “from scratch” jukebox system. More importantly though is that after installation of the base system, I had a basic, but fully working, command line Linux system at my disposal. This meant there were no unnecessary startup services, configurations and other settings which would have been useless, redundant or otherwise a hinderence to performance on this slow system.

• The Desktop Environment

  I chose to install XFCE as the desktop environment because it is the most lightweight of the ‘fully-featured’ environments. I would have liked to use an even lighter option, but of all the specialty and niche options available, I had never used any before, and this build was to be completed in a few hours. So, I chose XFCE which I found behaved no differently to GNOME, but was still relatively responsive despite limited system resources.

  To make the GUI look decent, I had to install a few additional packages that are not explicit dependencies of XFCE. They are listed below.

  • ttf-ms-fonts – the easiest way to make websites look nice is by installing this font package
  • midori – a lightweight, Webkit based browser for GTK+ environments. I chose this over Firefox due to the AJAX-heavy nature of the relaxx player. Webkit is supposedly superior in performance compared to alternatives

• The Webserver

  Now, you may be wondering why, with such a limited system, I was bothering with so many layers of abstraction between music, player and control. The reason is that none of the music playing applications I investigated (and there were quite a few) offered any functionality near that of a simple party jukebox. So, I had to use a web-based front end for mpd called relaxx, both of which I’ll talk about soon.

  The webserver of choice is lighttpd; a light weight simple web server, with all the features (and a lot more) required for what I had in mind.

• The Music Daemon

  Simply put: mpd. Or, Music Player Daemon, as it is less commonly known. I chose this system for multiple reasons: first and foremost, its awesome efficiency. With my 80Gb music collection catalogued and at my immediate disposal, mpd uses approximately three megabytes of system memory. Yes, you read that correctly: three. megabytes. If I go ahead and do something silly like, say, add my entire music collection into a single playlist, that number jumps to a staggering (!!!) eight megabytes. Yeah, I know. It’s ridiculous.

  Secondly, due to the daemon nature of mpd, you can use any frontend you like. You can use a text-based terminal application, you can use a GTK+, Qt or other, or you can use a web-based application, like relaxx player.

• The Music Frontend

  This is the party piece — the piece of the system that everyone gets to see. I chose relaxx player because it had some of the functionality that provides jukebox-like behaviour. Well, kind of. It essentially only had one major feature that made it stand out from a variety of other mpd front-ends: multi-user capability. Essentially, you could lock down certain features of the interface for anonymous users, and require a login for those functions. So, essentially that meant I could specify that anonymous users were only allowed to add songs to the playlist and press play. Meaning you had to log in to delete tracks, stop, pause or rewind, etc.

  The installation of relaxx was straightforward, but I had to install a few extra packages under Arch to make it work properly:

  • Arch wiki: Getting relaxx to work with Arch

  This was the only part of the system which didn’t quite work out so well. Its functionality was great, but due to the fact that it’s programmed entirely in AJAX, the old Pentium II powering the computer couldn’t quite keep up. It was slow to respond and not very nice to use, but it was usable. The music itself never skipped a beat (literally), but the performance of this frontend left something to be desired.

Fortunately, Firefox can be setup to do this, however it does require some tweaking of sorts. In the about:config page, you’ll find an option called network.automatic-ntlm-auth.trusted-uris which will enable Firefox to use Windows’ built-in NTLM authentication; allowing users to simply open the Sharepoint site without hassle. Unfortunately, having to set this manually on all the computers on the network that were already using Firefox, plus the additional worry of setting this manually on any new systems or users who decide to use Firefox seemed like an annoying task.

I Googled for a solution, but unfortunately there weren’t any that immediately performed the actions I required. Fortunately though, there does exist a nice utility by the name of FFDeploy which I was able to take parts of — specifically, the VBScript — in order to make possible what I had envisaged.

Essentially, all my script does is check for the existence of a Firefox directory buried within Application Data of the user logging on; if this exists, we copy over a special user preferences file, user.js which overrides or appends to same-values set in the global prefs.js (reference).

The bulk of the script I will keep seperate, as it can be had by downloading FFDeploy. My simple use is as follows:

GetINIString is a function provided by the VBScript in the FFDeploy utility; though it would be relatively straightforward to reconstruct, or write a sub to perform the same action for this specific usage. The line FSO.CopyFile() near the bottom is where we actually copy the user.js file from the server. When the condition isn’t met, we simply exit the if block and do nothing.

Simple, huh?

File’s here: asound.conf