personal website of ryan r. curtin
The l.o.u.n.g.e. contains several entertainment features that had to be custom-designed to fit the l.o.u.n.g.e.'s needs. With a complex speaker setup and many users, a method for music control had to be developed. Then, with a projector / computer setup, a method had to be set up to control the movies and the projector screen. Then, with so many computers, a complex (and entirely unnecessary) system had to be set up to provide all the desired services. On top of that, a system to control and perform maintenance on these systems had to be set up.
II. Central Music ControlOriginally, the desired characteristics of the music control system were:
The computer chosen to control the music was a dual Pentium II 400 MHz system running Debian. First, a GTK-based music player called Quod Libet was used [1] because of its simplicity and ability to handle large libraries. While it was suggested that Amarok could be used, this was not done, because (1) the suggester was an Amarok zealot and (2) running Amarok on dual Pentium II system gives performance similar to running Windows Vista on anything not cutting-edge. However, the graphical GTK interface of Quod Libet could not be used because the music-playing system did not have a monitor and was not usable. Instead it was desired that each user could control the music from their system. Quod Libet allows simple control of the music library through the command line:
$ quodlibet --playUnfortunately this system had several problems. Firstly, Quod Libet did not always do as it was told. Also, it heavily loaded the system and made it very tough to use, which was a consistent problem when a user wanted to stop the music very quickly. Users unfamiliar with a Linux prompt also generally had a hard time using the system.
Another problem was that Quod Libet cannot be run by more than one user. To combat this problem, a quodlibet group was added to the system, and each user who was to be allowed control was added to that group. A user called quodlibet was also added; this is the user who would run Quod Libet. Then, the control FIFO Quod Libet uses, located at ~/.quodlibet/control was symlinked to each user's home directory:
ln -s /home/ryan/.quodlibet /home/quodlibet/.quodlibetLastly, the python executable at /usr/bin/python was copied to /usr/bin/python-quodlibet and made setuid quodlibet and setgid quodlibet. The header of the Quod Libet executable had to be changed:
#!/usr/bin/env /usr/bin/python-quodlibetEventually, due to growing hate of the system, Ampache [2] was set up to replace Quod Libet. Ampache is a web-based frontend to mpd (music player daemon) [3]. Ampache relies on Apache (it is in part where it gets its name). A screenshot of an Ampache install (not the one used in the l.o.u.n.g.e.) is shown in Figure 1.
Unfortunately, Ampache had many worse problems that made it even more hated. Ampache only supported playlists, not a "random everything from library" mode, which was most commonly used. Instead, a user had to enqueue a number of random tracks to add to the playlist. If Ampache reached the end of the the playlist, it would stop. On top of that, enqueuing tracks took a very look time (100 tracks would take in excess of 5 minutes), and the system was easily crashable. The only redeeming quality of the system is the ease with which one could download tracks. In the Quod Libet system a user had to scp music from place to place. However, the bad outweighed the good significantly, and the music system was quickly switched back to Quod Libet.
After several months more of suffering through the drawbacks of Quod Libet, a music player called cmus was found [4]. This music player is ncurses-based, meaning that any user could control the music entirely through a simple terminal. This was a step up over Quod Libet, which only had command-line based control. However, cmus is not a client-server model (like Ampache was), so some hacking needed to be done to allow multiple users to control the same cmus instance.
GNU Screen [5] was chosen as the backbone to the music control system due to the ability to resume a screen session from anywhere, and since multiple terminals could access the same screen at once. However, instead of setting up permissions to allow multiple users to access the same screen session, a cmus user and group were set up. Then, in /etc/sudoers, the following was added:
%cmus ALL=(cmus) /usr/local/bin/resume_cmus_screenThe script at /usr/local/bin/resume_cmus_screen was merely a wrapper script (sudo does not allow specification of arguments to privilege-escalating commands):
#!/bin/bashOn top of this, another very simple script was written:
#/bin/shWhile the chmod command used in that script opens up security vulnerabilities, these are closed with the l.o.u.n.g.e. security tool and the fact that each user who has an account on the system and could exploit the vulnerability knows they could have the l.o.u.n.g.e. security tool applied to themselves. The chmod command was necessary; otherwise, the screen session, running as user cmus, would be unable to write to the TTY (which was owned by the original user).
To complete this system, the users who were to be given control of the music needed to be added to the cmus group. Then, a simple Debian init script was written to start the cmus screen session on boot. That script can be found here. A screenshot of the system in use (with alsamixer open in an adjacent window) can be seen in Figure 2.
Having a centralized music server was not much use unless everyone in the l.o.u.n.g.e. had a simple way of knowing what music was playing. A status display was designed to prevent the continual "What is this?" question from those too lazy to keep a shell open on the music control system. Figure 3 shows a picture of the completed status display, in use.
Figure 3. This stack only fell over once. |
An original design requirement was that the monitor being used to display music status must also play The Matrix screensaver; otherwise, it would be unlike every other monitor in the room. Therefore, it was decided that the XOSD library [6] would be used to write music information on top of the Matrix. At the time this was decided, the music was being played through Quod Libet. It was known that song status was kept in the file ~/.quodlibet/current; therefore, a script was written to collect the song information (title, artist, album, date, tracknumber) and write it onto the screen. After the switch to cmus a few months later, some trickery had to be done to get the song information into a file. The following command was added to ~/.cmus/rc: set status_display_program=/home/cmus/.cmus/dump_dataThe script at /home/cmus/.cmus/dump_data, which dumps the currently playing song information into a file called 'info', is: #!/bin/bashrm -f /home/cmus/.cmus/info while [ ! -z $1 ]; do echo "$1 $2" >> /home/cmus/.cmus/info; shift shift done |
In 2008, when the l.o.u.n.g.e. moved to apartment-style housing, the music display monitor was no longer near the system controlling the music. To combat this problem, another system (a Mac G4 Cube) was set up, and cmus was told to scp the 'info' file to the display system, by modifying the dump_data script. However, SSH keys had to be set up so that a password did not need to be entered. Once this was done, the OSD script was moved to the display system and modified accordingly. The current script can be found below.
Links to all of the relevant files (except the SSH keys) can be found below. Init scripts for Debian to start the music display program are also included.
It should be noted that one of the problems with the get_song_info script is that the Matrix screensaver will clear the screen every several seconds (seemingly random), meaning that if XOSD writes information to the screen, it may disappear after a couple of seconds. The script accounts for this by re-writing to the screen every three seconds. Another drawback of the system is that the time it takes to scp the song information is approximately a second, so the display may be wrong and confuse viewers for up to the first four seconds of a song. The l.o.u.n.g.e. engineers have faith that no nervous breakdowns will occur in this period, and as such, no attempt is being made to fix this problem.
III. Central Movie ControlWith the advent of a large projector screen, a method needed to be developed to watch media on the projector. The computer chosen to control the projector was bigred, an old Halloween costume that had a Pentium 4 system built into it with the help of styrofoam and tape. This system was chosen since it was the only one near enough to the projector to use a VGA cable.
The very basic design of the movie playing is similar to that of the music; one user ('display') owns the X server (in the music system, one user owns the music playing application). In this setup, every user has a copy of the .Xauthority file belonging to the display user, and therefore can start processes that use X (specifically mplayer [7]). On system startup, an init script starts the X server as the display user, copies the .Xauthority to all authorized users' home directories, and corrects the permissions of /dev/dvd (so all authorized users can play DVDs). A copy of this startup script (written for Gentoo) can be found here.
A utility script was written for playing videos (essentially an mplayer alias with options), so that users did not have to remember the long string of options to pass to mplayer. This script (found here and below) has the odd quirk of choosing to play DVDs in French or some other non-English language for reasons unknown. The script is shown below.
#!/bin/bashWhile this script could certainly be improved on it works well enough for the purposes of the l.o.u.n.g.e., and for that reason has not been modified (this means that there is not enough motivation to fix it).
b. Background RotationDue to the unavoidable dead time between projector turn-on and entertainment commencement, it was decided that an entertaining picture should be used as the background to the minimal fluxbox environment used on the movie-playing system. The original entertaining picture can be seen in Figure 5. Later, as attention spans dwindled, the picture was changed. Later still, the picture was changed again. After some period of manual picture-changing, it was realized that a simple script to choose the background randomly was required.
The program fbsetbg made this endeavor significantly easier, because with the '-r' option it randomly chooses a background from a directory of images. Therefore, a very simple script was created to rotate the background, but only if mplayer was not in use. This script can be seen below and downloaded here.
#!/bin/bashThis script was placed in the crontab of the display user, run every minute. Originally, the second fbsetbg and sleep 30 were not included, since the attention span per picture of viewers was approximately 60 seconds. However, over time, this attention span dwindled. The modification had to be performed to the script since crontab's lowest time span is minutes, not seconds. It is likely that in the future the delay between background switches will need to be decreased to 15, 10, 5, and eventually 1 second to keep up with the epileptic tendencies of today's fast-moving world.
To complete this setup, the directory /home/display/.fluxbox/backgrounds/ was symlinked into each user's home directory, and each user was given write permissions. Then, any user could download any inane image and it would be added to the repository of random, mildly entertaining images.
IV. Physical Computer Control With such a needlessly complicated computer setup,
a needlessly complicated method for physically interfacing with the computers
was required, for those unfortunate times when networking was unavailable. For
this, a series of daisy-chained KVM switches were used. A 2-port
keyboard-controlled Belkin KVM switch was used as the head of the chain; one
side of this switch went to the left stack, and one side went to the right
stack. Each stack had its own 4-port KVM (one stack had an additional 2-port
KVM which didn't work but was nonetheless connected), which was
pushbutton-controlled. A diagram of the needlessly complicated setup can be
found in Figure 6. Each KVM port was given a textual name and each cable was
labeled; this way, it was easy to tell which KVM was hooked up to which
system.
It should be noted that with the approximate cable setup time of 45 minutes to an hour for this, the KVM was only actually ever used a couple of times. However, without all of these extra cables, the cable zoo behind one of the stacks (shown in Figure 7) would be nowhere near as entertaining and ridiculous.
In this section the unnecessary complication of the numerous computers used in the l.o.u.n.g.e. are explained. Originally, the members of the l.o.u.n.g.e. did not possess very many computers. However, over time, through the magic of craigslist many systems were amassed. While many systems originally did not have a use, sooner or later a use was found to justify their existence. Below, in Figure 8, a network services map is shown. Laptops are omitted.
Figure 8 clearly shows numerous services being provided to the external world through hampton, the gateway system. Several systems provide HTTP, which is all provided on port 80 due to the use of pound [8]. For example, this page was provided through turbine, but the HoverRace Trac page was served via brakes, the svn/Trac host. The system that provides DNS, marijuana, only provides this service internally (for internal name resolution). Printing support is through brick, an old Thinkpad PII laptop. While the diagram does not include lines to indicate it, SSH is available internally to all boxes (except a few Windows boxes). Many systems also have SMTP set up, but all of them send outgoing email to tortoise, the mailserver (and do not receive incoming mail). The systems cardboard, turbo, popcorn, and pizza do not have any shown services on the diagram; however, cardboard acts as a screen [5] server, popcorn is an additional rdesktop host, pizza was meant to be an LDAP server (but as of yet has not been completed), and turbo is a 486 that is not really capable of doing anything at all.
All of the servers in the upper left half of the diagram are in the server room; the four workstations are in the computer room, and the three display systems (bigred, fishbowl, and cmcfee) are in the main lounge. It should also be noted that the median processor in all of these systems is approximately a middle-class Pentium II. The lowest-end system is a 486 (turbo) and the highest-end system is a needlessly powerful Core 2 Quad Q6600 (buddha).
Realistically, all of the services provided by this network could be consolidated onto one fairly modern box; however, since this is not as cool or complicated as the above-described setup, it is not in use. Another likely reason for this setup is lack of money. Nearly all of the computers used here (except desktops) were put together for $100 or $150 total.
VI. Uncompleted Control ProjectsOne of the first control projects for the l.o.u.n.g.e. was a controllable power strip. This power strip connected via parallel port (DB-25 connector) to a host computer, which took commands describing the state of each of the switches. Each strip was controlled by a high-power relay, on a hand-etched PCB. The input was 120 VAC, from a wall socket, and the output was 8 controllable 120 VAC connectors. However, it was declared to be too dangerous by its designer (who, incidentally, is not the author of this page), who also once suggested drying a wet couch with a blow-torch. As a result of the denizens of the l.o.u.n.g.e. preferring to stay in a not-on-fire state, the project was not pursued further. "Hadji", as this project was titled for an unknown reason, is pictured below in Figure 9, under the protective shielding of a cardboard box. A video of the Hadji controlling three lights is available here, but unfortunately it does not include the entire device catching fire.
At one point, after seeing a similar senior design project by a fellow Georgia Tech engineer, it was considered that a phone-based control method for the room could be created using a spare system and the Perl Modem::Vgetty module [9]. This system could allow number-based commands for the control of the l.o.u.n.g.e. and could also call someone if a machine was detected to go down or if problems occurred. Possible commands could include emergency cooling (shut down all unnecessary systems), play music loudly (to annoy residents), control lights through the Hadji, which was also never finished, and check for new IMs or messages; the possibilities are nearly endless. However, the time was never found to pursue this project properly, and the necessity for it never developed.
One problem that was never properly addressed was the downtime of systems during a semester break. Since nobody was in the l.o.u.n.g.e., these systems could not be rebooted during this period, and were down until residents returned. One proposal to address this was to take a spare system and line up its cd drive with the power/reset button (or two CD drives, one for each) on the system to be rebooted. However, this was not pursued, because as the Roman poet Juvenal once said in Latin, "Who will reboot the rebooters?" Another concept was to use a mobile robot with a webcam (or some other watchable interface) and a pointy appendage to reboot systems. This was not pursued due to the sheer amount of work it would be. Instead, the used solution to this problem was to grumble and complain all vacation long, when the systems (almost inevitably) crashed the day after all the residents of the l.o.u.n.g.e. had gone home.
VI. Bibliography