l.o.u.n.g.e.
Control
|
|
www.igglybob.com l.o.u.n.g.e. Control |
|
the main - main page - about me - l.o.u.n.g.e. - r.e.t.a.r.d. - s.o.l. meter - s.c.r.e.a.m. - videos the l.o.u.n.g.e. - overview - 2006 edition - 2007 edition - 2008 edition - control the s.c.r.e.a.m. - main page - tech review - proposal - draft summary the r.e.t.a.r.d. - overview - assignment - proposal - requirements - timeline - the core the s.o.l. meter - overview - car modification - meter design - meter input |
I. Introduction
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 Control a. Music Player Originally, the desired characteristics of the music control system were: - Controllable by all users - Able to handle very large libraries of music - Simple to use 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 --play $ quodlibet --pause $ quodlibet --next $ quodlibet --enqueue='album="Europe \'72"' $ quodlibet --unqueue='artist=Marilyn Manson' Unfortunately 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/.quodlibet Lastly, 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-quodlibet Eventually, 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. 
Figure 1. The l.o.u.n.g.e. residents listen to much more refined music, like G.G. Allin. 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_screen The 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/bash screen -rAx -S music On top of this, another very simple script was written: #/bin/sh chmod 777 `tty` sudo -u cmus /usr/local/bin/resume_cmus_screen While 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. 
Figure 2. Even Unicode characters are displayed correctly. 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.
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. - .cmus/rc - cmus rc file - dump_data - run by cmus to dump the currently playing song information - get_song_info - display song information using XOSD - fishbowl_x - Debian init script to start display 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 Control a. Movie Playing With 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. 
Figure 4. Cooling is not an issue due to ear-mounted 90mm fans. 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/bash #2007.03.09 - removed -alang en so -aid works. DISPLAY=:0.0 mplayer -vo sdl -cache 8192 -fs -zoom "$*" While 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 Rotation Due 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. 
Figure 5. This was entertaining for approximately fourteen seconds. #!/bin/bash # # Simple script to rotate background if [ `ps -ef f | grep mplayer | wc -l` -le "1" ]; then DISPLAY=:0.0 /usr/bin/fbsetbg -r ~/.fluxbox/backgrounds/ -f sleep 30; DISPLAY=:0.0 /usr/bin/fbsetbg -r ~/.fluxbox/backgrounds/ -f fi exit 0; This 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. 
Figure 6. Such entertaining switch combinations as 'junk-oz' or 'funk-zop-ack' could be used. 
Figure 7. Masochist's delight. 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. Needs more lines. 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 Projects One 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. 
Figure 9. Yes, seriously, a blow torch. 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 [1]. Quod Libet - http://code.google.com/p/quodlibet [2]. Ampache - http://ampache.org [3]. Music Player Daemon Wiki - http://mpd.wikia.com [4]. cmus - ncurses based music player - http://cmus.sourceforge.net [5]. GNU Screen - http://www.gnu.org/software/screen/ [6]. Ignavus - Software - http://www.ignavus.net/software.html [7]. Mplayer - The Movie Player - http://www.mplayerhq.hu/ [8]. Pound - http://www.apsis.ch/pound/ [9]. Modem::Vgetty - http://search.cpan.org/~yenya/Modem-Vgetty-0.03/Vgetty.pm Back to the main l.o.u.n.g.e. page! |
