Analysis of TeamViewer
Ludwig and Clemens from Weimar and Brendan from UCSD worked to analyze the TeamViewer teleconferencing software.
Our approach was simply to first attempt a more traditional, conference like discussion over the software, discussing its merits, features and usability. This allowed us to evaluate the functionality of the application as intended. Connection to the application was made through both Mac OSX and iOS.
After investigating the base functionality of the software, we attempted to "break" or "misuse" the software to create musically interesting sounds with no outside processing beyond mic positioning and volume. This allowed us to evaluate the potential of the software for our interests, as an aleatoric source of sound and telematic platform for music performance.
The Software
TeamViewer is a teleconferencing software, geared towards setting up "meetings" between remote users, with an emphasis on presentation and screen sharing. The software's most significant features relate to the interactivity between a displayed screen and users, with several levels of participation (audio only, video only, etc.) selectable for different members of a meeting. It also supports large numbers of present users, and generates unique meetings with invitations and private ids.
Sound Control
The control available in TeamViewer for audio is limited, but has a few important features. First, it has a variable volume, separate from that of the internal mic level control built into the OSX operating system. More interestingly, the application includes a variable noise gate, with an associated volume meter, allowing a user to easily select a threshold for a noise gate. Outside this relatively noise threshold (which appears to act as a simple gate with slightly ramped amplitude crossfade when cutting in and out) there is only a selection of input and output destinations.
Quality of Transmission
The immediate impression of the quality of video and audio transmission was poor. The video never quite worked (stayed frozen through most of the session) and the audio cut in and out quite a bit, with significant bit-rate reduction effects. One feature that did work quite well was the screen-sharing capabilities, which allowed us to compare our methods for recording and testing the audio latency.
Sound trip latency varied, but the clearest measured data (as our audio was generally quite poor) resulted in 590 ms roundtrip latency. This software is therefore incapable of supporting any interactive performance beyond cue-less improvisation.
Musical Uses
While the quality of transmission is quite bad, the ability to eliminate or heighten the noise threshold of the transmitted audio, coupled with the bit-rate reduction and lossy connection made for interesting musical experimentation.
As stated above, the latency prevents this software from use in actual interactive situations, but allows for meaningful (if limited) control of transmitted feedback loops. These controls, along with the simple parameters of mic placement, type and volume and speaker placement, type and volume allowed for an interesting sound space. While decidedly bright and noisy, larger musical forms and aims could be followed with some experience.
Example
Here is an example of the sound quality during the feedback experiments, as directly recorded without any processing or filtering in San Diego:
Composed Piece
The piece below contains two sections, using the recorded sounds that occurred over the course of the session. They have been stitched together. Each side of the transmission (here in San Diego and Weimar) recordings of the transmitted audio were rearranged and replaced into 45 second mono clips. These clips were sent off the to other locale, where it was heard and reacted to with other sounds from the session. Each locale is panned to one or the other side, resulting in a two part, binaural piece lasting 1'30".