How Can I Create an Internet2 Performing Arts Event? By Philip Galanter galanter@nyu.edu

[Ed: Links to web pages which have become inactive since the publication of this article have been enclosed in curly brackets { }. Replacement links have been provided where possible.]

Do you have an idea for an Internet2-based performance? Internet2 is still an experimental network and very much a work in progress. Each performance is unique, and so the best first step for interested faculty would be to contact the author of this article to discuss your ideas and options. The Arts Technology Group (ATG) of ITS Academic Computing Services has served in a systems integration function for all NYU Internet2 performances to date, with the close help and cooperation of ITS Network Services. Here, in broad strokes, are some basic questions and considerations for those interested in using Internet2 for art events.

Internet2 includes the Abilene network, which extends to every state in the U.S., as well as numerous university and regional networks. About 80 universities are connected to Internet2 as well as a number of research organizations. Universities which are not members of Internet2 are bridged to Internet2 schools via the regular Internet, but lack the robust network performance that Internet2 provides. While this is not noticeable when sending e-mail, they will usually find sending high quality video to be impossible. So, all of the sites in the performance will have to be at an Internet2 member university. These members are listed at the Internet2 website at: {http://www.internet2.edu/html/universities.html} Replacement URL: http://members.internet2.edu/university/universities.cfm.

It is also worth noting that the Internet2 community has significant links to similar high-performance networks in other countries, therefore, collaboration with artists in other parts of the world may be possible.

How well-connected are the performance spaces?

Even though a given university may be connected to Internet2, different locations on the campus may have varying degrees of connectivity. This introduces the so-called "last mile problem." A determination must be made as to whether Internet2 capacity crosses the campus the last mile to the performance space. Indeed, on many campuses, performance spaces may have no Internet connectivity at all. And those that are networked may be attached to a campus backbone that is too congested to deliver Internet2-like performance.

Here at NYU, we've built a special Internet2 subnet which bypasses the commonly used NYU-NET campus backbone. Supported locations include the Black Box Theater in Pless Hall, the Loewe Theater at 35 West 4th St., the Studio for Digital Projects and Research in the Bobst Library, the ITS Faculty Technology Center, the Music Depart-ment recording studios in the School of Education, and the Center for Advanced Technology. In addition, temporary connections have been made to the Cantor Film Center. Internet2 events at any of these locations will not have any "last mile" problems.

Researching the last mile at your collaborators' campus requires a technical assessment with the help of the central networking staff at that university. The Arts Technology Group (ATG) here at NYU can broker this discussion as part of our integration function.

A CODEC is a device that accepts video and audio signals as input and converts them to a data stream as output. This data stream is sent over Internet2 to the far site, and then a corresponding CODEC on the other side converts the data stream back into video and audio. Although some software CODECs running on personal computers are available, in general, Internet2 performance events use dedicated hardware CODECs for improved performance and quality.

Generally speaking, CODECs are proprietary devices that do not offer interoperability at this time. Thus, the same brand of CODEC must be used at each participating site. At various times here at NYU we've used computer-based CODECs, including CUSeeMe, Cisco IP/TV and DVTS (beta software from a project in Japan), and hardware CODECs from VBrick, OptiVision, and Litton.

ATG owns some VBrick CODECs that we can offer for use in NYU projects, and we can even ship them for use at other schools performing with NYU. Again, ATG can broker this discussion and implementation with your collaborators.

Early in the planning stages, a decision will need to be made regarding the media plan. For some performances at NYU, a single video and stereo audio signal to and from the collaborating site has allowed for a technically simple, but artistically rich, performance. The most technically complicated performance to date, "The Technophobe & The Madman", required three channels of video and six channels of audio being sent from NYU to Rensselaer Polytechnic Institute (RPI), and an additional three channels of video and six channels of audio being sent from RPI to NYU.

Each CODEC can typically send and receive a single video channel and two channels of audio. But, along with acquiring the needed CODECs, some consideration must also be given to the total bandwidth the multiple streams will require. This is the bandwidth budget. For example, "The Technophobe & The Madman" required six VBrick CODECs and a maximum of eighteen Mbps in bandwidth.

There will always be a delay between the time when the camera and microphones pick up a performance at one site, and the time when performers at the far site see and hear it in the monitors. In the context of networking, this delay is called latency.

Typically, the latency we've experienced with Internet2 performances is about 1/4 to 1/2 of a second. While this is not a lot of time, it is quite audible and usually visible, and it will seriously impact traditional music and dance performance where the players are trying to interact between the sites.

For example, a saxophone player in New York and a bass player in Los Angeles will have a very difficult, if not impossible, time playing tight fast improvisational jazz together. How-ever, asking the bass player to provide a solo rhythm that the saxophone player can then improvise over will work quite well. The two parts can be mixed in sync in New York, and sent back to the Los Angeles audience. However, the audience in LA will see the bass player pluck a string a noticable fraction of a second before they hear it mixed with the saxophone in the PA system.

In general, successful Internet2 performances are written, composed, and designed specifically for the Internet2 medium. Typically, different sites trade off leading and following, the parts are allowed to be a bit loose, and the slight delays are built into the aesthetic of the performance.

Consider a theatrical play performed between two sites, where one actor is in New York and the other actor is in Los Angeles. When the actor in NYC delivers a line, it is picked up by a microphone and, with a slight delay, played over the speakers in Los Angeles. The LA actor then delivers a line that is picked up by a microphone and, with a slight delay, played over the speakers in New York.

While this set-up allows for good interaction between the actors, it also introduces a technical problem. If the NYC microphone can "hear" the speaker playing the signal from LA, and the LA microphone can "hear" the speaker playing the signal from NYC, this creates an echo loop and the actors will sound like they are performing in an echo chamber. And, if the feedback is strong enough, a painful level of noise can quickly build up.

Audio feedback is always a consideration with live amplified sound, even in a single site performance. It is an especially difficult problem to deal with in a networked performance because the sound reinforcement and monitoring at each site will impact all of the other sites. Turning up the sound in NYC might create feedback in LA.

There are a number of technical solutions to this general problem, including the use of headphones or wireless in-ear monitors, careful microphone and speaker placement, riding gain at the mixing board, and the use of noise gates and other echo suppression electronics. The point to remember is that audio requires more planning than usual for a multi-site performance, and sound checks will be much more time consuming than those for single site performances.

For the general contemporary audience, commercial television more or less sets the standard in terms of video quality expectations. Even though cable television and DVD can deliver a superior picture, audiences tend to not consider video problematic unless it is notably worse than broadcast television or VHS tape.

Most hardware CODECs can deliver at least VHS quality video, although a trained eye may notice subtle compression artifacts. Network problems can, of course, cause dropped or frozen frames. While most CODECs can be configured to deliver greater video quality at the expense of greater bandwidth, greater bandwidth increases the possibility that network problems will result in dropped frames. Therefore, a careful balance must be struck regarding video quality and the bandwidth budget.

The ATG has had very positive feedback on image quality to date, even when the videos have been projected on large screens. It is worth noting, however, that projecting video for live stage performance has its own set of technical challenges. Projected video "wants" to be on a dark stage, and cameras "want" a very bright stage, so the mix of live action and projected video will require that the video crew and the lighting designer work very closely together.

Some of these considerations may seem to be a bit daunting, and multi-site Internet2 performance projects do require careful planning and implementation. But the rewards are great, and here at NYU we now have significant experience using Internet2 as a new medium for live artistic expression--expertise that we will happily use to help you plan and implement your project. We look forward to hearing your ideas and project proposals!

For additional information about Internet2, please read Philip Galanter's other article in this issue, "Internet2: The Next Generation Theatre".

Posted Fall 2001. Revised January 26, 2004.