Hole in the Earth

"Hole in the Earth" (2001) is a work by Maki Ueda, realized in cooperation with V2_lab.

Hole in the Earth

Hole in the Earth: Rotterdam

Hole in the Earth is an installation for the public space.

The idea is to create a virtual tunnel through the earth, connecting two public spaces in Rotterdam and Shanghai, so that communication with the other side is possible. Each end of the 'tunnel' consists of a steel turret with a bullet-proof glass lid, sticking about 30 cm (1 foot) out of the pavement. Inside is a good-quality SVGA display (plasma-screen), an AXIS 2120 Intelligent Webcam, speakers and a microphone. The screen is facing upward, so the audience has to look down (into the earth) to see the images from the other side, thereby coming into view of the webcam, capturing images for the other side to see. The same principle is used for the audio; the microphone is plugged into the server, which encodes the received signal as a low-bitrate MP3-stream, which is unicast to the other side, and played back by the other server.

Concept & design by Miss Maki Ueda.
Production: Maki  Ueda & CELL (Initiators of Incidents) within the framework of CELL's "Homeport" project for "Cultural Capital Rotterdam 2001".
The technical system design and software & hardware development: V2_Lab for the Unstable Media, Rotterdam.


Technical description

The system is fully symmetric. That is, the Rotterdam server is doing the exact same things as the Shanghai server (with the exception of the internet connection itself, more about this later). So it will suffice to describe the workings of one end of the 'tunnel' and imagining the other end behaving identically.

The server is running Debian Linux, and its tasks can be separated into 5 distinct groups:

  1. Media Input (Webcam, Microphone & MP3 encoder)
  2. Encoding & Copying (MP3 Streaming server, FTP-server & scripts)
  3. Media Output (MP3 player & X-Windows SVGA display)
  4. Internet Connection (Only this part is different for the two servers...)
  5. Admin, Debugging & Process management

Media Input

The AXIS 2120 webcam is a camera with a built-in embedded-Linux system. It has a UTP ethernet connection, a built-in webserver and FTP-server and a built-in JPEG-compressor. It was retrofitted with a 145-degree wide-angle lens. The camera is connected to a local (private) ethernet-network on the second ethernet-card of the server. So the camera is NOT directly accessible from the internet, only through the http mirror that's running on the server. It is configured to send a hi-res JPEG image to the (local) server via FTP every second. We're using 704x576 image resolution, at a relatively high JPEG-compression-level. All the image-grabbing, compression and FTP upload is handled by the webcam, all the server has to do here is check when a fresh picture is uploaded.

The microphone is simply plugged into a soundcard (Creative/Ensoniq SB-PCI-128) and the incoming audio is captured & encoded as MP3 by 'Liveice' (live audio streamer) and 'Lame' (MP3 encoder).

Encoding & Copying

The MP3 audio stream is handled by 'Icecast', a nice, configurable, multi-mode streaming audio server. Basically Icecast 'holds' the stream's URL and waits for a client to connect. So the audio played back at one end of the tunnel is 'pulled' from the streaming server at the other end. For monitoring & debugging purposes, it's possible to listen to the audio stream from either end on any web browser (with mp3 audio playback capabilities).

The process copying the uploaded image from the webcam to the other server is a piece of custom software, written by Simon de Bakker, V2_Lab. Basically, it waits for a fresh picture from the webcam (by looking at the picture's inode-number and/or creation time) and when it gets one, it calls FTP to upload the image to the other server. Therefore, images are 'pushed' to the other end to be displayed.

We've defined a macro for FTP that will continue uploading pictures as fast as it can, keeping the connection open, because we found that the uploading of the pictures takes longer than one second, so there will always be a fresh image uploaded from the webcam by the time FTP is done uploading the previous image to the other server.

Due to unpredictable Internet traffic density, it is possible for the FTP connection between the servers to stall. For this eventuality, we have implemented a timeout; if an FTP transfer takes longer than 30 seconds, the process is killed and restarted, establishing a new connection.

Media Output

The received images from the other server are stored locally, and another little program by Simon checks for the arrival of fresh pictures, and displays the incoming pictures full-screen on the X-windows display.

This software uses the same principle as 'sscp' (the FTP-copy process) to determine when there's a fresh picture available, and uses SDL (Simple Directmedia Layer / Library) to display the JPEG images.

The audio-stream is played-back using 'mpg321', the simple MP3-audio player which also uses SDL.

It would be preferable to use mpg123 instead, since it promises better quality, and has functions to 'retrain' the stream once connection is lost. Unfortunately, it has so far not proven possible to use mpg123 in full-duplex mode (that is, mpg123 will not open the audio device for output when it's already being used for input). mpg321 (or rather: SDL) DOES support full duplex, but the player will sometimes 'hang' without quitting when the stream is lost, which makes it difficult to keep the audio going.

Internet Connection

The connection of each server to the Internet is different for the two locations, due to the availability / affordability of Internet connections in Rotterdam & Shanghai.

The Rotterdam server is set up inside the office of CELL. The "Hole" is made in the little 'park' at the beginning of Diergaardesingel, in Rotterdam Centre (a corner of Rotterdam's Chinatown), just outside the CELL office. For this installation, CELL have acquired an ADSL-MXstream subscription (from xs4all.nl). It's an ADSL-over-ISDN set-up; the ADSL modem is an external box which connects to an ADSL/ISDN splitter at one end, and has a standard UTP-Ethernet port on the other side for the server. The MXstream subscription comes with four IP addresses, but only one is in use for the "Hole" server. Depending on available bandwidth, it is possible to establish a LAN at the CELL office, using the "Hole" server as firewall & masquerading gateway, but this is a separate project, which will only be considered once the "Hole in the Earth" installation is fully functional with bandwidth to spare.

The Shanghai server is set up inside the Chinese State Library of Shanghai, connected to the library's LAN, where there's supposedly a 2MB backbone connection to the Internet, but it seems that this 2MB-Link is not just the for library, but the WHOLE of Shanghai (bandwidth really is a problem here!)

Also, the LAN inside the library is behind a firewall. Obviously, the "Hole in the Earth" server has to be able to communicate to/through the internet in BOTH directions on several ports, so we had to have the network administrator of the library route our server through the firewall to a real-world IP, opening the ports for FTP (20 & 21), HTTP (80) , SSH (22) , NTP (123) (time), DNS (53), and 8000 (MP3-audio-stream).

The political implications of opening the main firewall of Shanghai Library for even a short period of time are quite serious, and obtaining an official permission for the Library's Network Management to accommodate our request was NOT easy, even for the few hours of set-up & testing we did, and the two-hour presentation of the prototype-installation on June 9th 2001. To get them to open the firewall permanently, for a period of up to three years, might still prove very, very difficult. The Library's firewall is the only issue there we have to deal with, aside from bandwidth restrictions which are outside of our control.

Administration, Debugging & Process management

We chose to use a Linux system for "Hole in the Earth" for several reasons:

  • Reliability; a properly-configured Linux-system will not crash.
  • Remote access; using SSH, the software & configurations of the "Hole"-servers can be monitored, updated and maintained from anywhere in the world.
  • The level of process automation and custom-built processes that can be achieved using standard Linux tools & scripts is unparalleled by any other OS.
  • It's free!

The "Hole in the Earth" system relies heavily on 'Cron' (Unix' periodic command scheduler) to start or restart processes that have stopped or been killed. Every time a process is (re)started by Cron on any of the two servers, Cron sends me (Stock) an e-mail to that effect, so that I'm kept up to date on what's going on. Here's a list of processes used by "Hole in the Earth" plus a short description of what they do, how they can fail, and what to do about it if they do.

  • ProFTPd
    FTP-server, receives pictures from the webcam for uploading, and receives uploaded pictures from the other server. Restarted by Cron when it dies.
  • Apache
    HTTP-server, for admin & testing purposes. Posts the received pictures (local AND remote) on the web, and mirrors the built-in configuration pages of the webcam. Cron restarts it when dead.
  • IceCast
    MP3 streaming audio server. Unicasts the audio-stream to the other server (once the remote mp3 player has connected). Cron restarts it when necessary (when Icecast restarts, the local Encoder [LiveIce] and remote mp3-player will die & restart too).
  • Liveice & Lame
    Live Audio Streamer & MP3 encoder. LiveIce takes input from the microphone, pipes it into Lame for mp3-encoding, and feeds the mp3 stream to IceCast. Once LiveIce is up & running it doesn't die. However, before LiveIce can be (re)started, the local mp3-player has to be killed to avoid a conflict with the audio device. Once LiveIce is running, the mp3-player can be restarted without problems...
    LiveIce is GPL, Lame is GPL but non-free in some countries (in the Netherlands & China no problem)
  • mpg321
    The mp3 player. This one has a problem; the player sometimes 'hangs' after the stream is lost, but doesn't die, so Cron will NOT notice the audio stopped, and will not try to restart it. This problem could be solved by using mpg123 instead, but then another problem arises with regard to opening the audio-device for input & output simultaneously.
    GPL (?)
  • sscp
    This is a little program written by Simon de Bakker, V2_Lab, which determines the status of the JPEG images being uploaded from the webcam, and starts FTP to copy any fresh picture to the other server. Started by Cron, restarts itself after a timeout (independent of Cron).
    Custom-made software
  • Gat & X
    'Gat' is Simon's program that uses SDL to display the incoming JPEG's full-screen on the X-windows display. It runs without a windowmanager and politely hides the mouse pointer. Gat is started by xinit, and X itself is started by Cron and hasn't been known to die yet.
    Gat is custom / GPL (SDL), X is GPL
  • PPPd & PPTP (Rotterdam side only)
    The Point-to-Point-Protocol daemon and Point-to-Point Tunnelling Protocol are used for the ADSL modem. The connection is brought up at boottime, and restarted by Cron if it fails.
Document Actions
Document Actions
Personal tools
Log in