Analysis of TeamViewer
Ludwig and Cornelius 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 (up to 25 participants), 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.
Setup, configuration and usability
Intricate, defective and not intuitive.
- We had several problems with the account validation and login
- One can't easily find people without their exact Alias
- To start a meeting you have to create an ID and mail this number
- The start preferences are questionable (i.e. in the meeting the screensharing turns on automatically)
- iOS doesn't support video
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.
Subjective experience
It was very difficult to start a meeting and communicate. It was a relief to switch to skype at the end.
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.
Examples
Here is an example of the sound quality during the feedback experiments, as directly recorded without any processing or filtering in San Diego:
Transmission recorded in San Diego <flashmp3 id="exampleSD">exampleSD.mp3</flashmp3>
And here an example of the sound quality of Brendan normally speaking, recorded in Weimar:
Transmission recorded in Weimar <flashmp3 id="TeamViewerSpeech.mp3">TeamViewerSpeech.mp3</flashmp3>
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 (San Diego L, Weimar R) resulting in a two part, binaural piece lasting 1'30".
<flashmp3 id="MakingConnection(Brendan-Cornelius-Ludwig).mp3">MakingConnection(Brendan-Cornelius-Ludwig).mp3</flashmp3>
Musical Conclusions
While useless as a telematic performance tool, the software did yield very interesting results due to its lossy and inconsistent transmission. These could be learned and controlled with some experience and understanding of the software's functionality. After this investigation, there seems potential for some piece of loudspeaker music, especially concerned with the uses and themes provided by the topic of telematic performance and its inherent issues (which are highlighted by this software).