Technical Report

Transcripción

Technical Report
Technical Report
Abstract: This technical report analyzes the state of the art of technology for musical real-time
interaction over computer/data networks (NMP, Networked Music Performances). It describes the
challenges that it introduces and the software implementations that make NMP possible at present. It
also presents a practical experience based on NMP where a group of musicians, located at geographical
distant places, interact over a network to perform as they would if they were located in the same room.
Document Id.:
CESGA-2014-003
Date:
01/05/14
Responsible:
Natalia Costas and
Ivelina Atanasova
Karagyulieva
Status:
FINAL
Technical Report CESGA-2014-003
Networked Music Performance
May 2014
Galicia Supercomputing Centre
Summary:
This technical report analyzes the state of the art of
technology for musical real-time interaction over
computer/data networks (NMP, Networked Music
Performances). It describes the challenges that it
introduces and the software implementations that make
NMP possible at present.
It also presents a practical experience based on NMP
where a group of musicians, located at geographical
distant places, interact over a network to perform as
they would if they were located in the same room.
Keywords:
Networked
Music
Performance,
Latency,
High
performance data network applications, RECETGA
(Galicia Science and Technology Network)
License:
Author: Ivelina Atanasova Karagyulieva
Author: Natalia Costas Lago
Copyright notice:
Copyright © CESGA, 2014.
See www.cesga.es for details on the copyright holder.
You are permitted to copy, modify and distribute copies of this document
under the terms of the CC BY-SA 3.0 license described under
http://creativecommons.org/licenses/by-sa/3.0/
Using this document in a way and/or for purposes not foreseen in the
previous license requires the prior written permission of the copyright
holders.
The information contained in this document represents the views of the
copyright holders as of the date such views are published.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED BY THE
COPYRIGHT HOLDERS “AS IS” AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL CESGA BE LIABLE FOR
ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
IN ANY WAY OUT OF THE USE OF THE INFORMATION CONTAINED IN THIS
DOCUMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Table of Contents
Changes history ............................................................................... 5
Glossary........................................................................................... 6
Conventions ..................................................................................... 7
1.
Introduction ............................................................................ 2
2.
Real time distributed performance technical challenges ......... 3
2.1
Latency and jitter .................................................................... 3
2.2
Network requirements .............................................................. 5
2.2.1
Bandwidth ........................................................................... 5
2.2.2
Network traffic management for NMP ...................................... 6
2.2.3
Network latency.................................................................... 7
2.3
Servers .................................................................................. 7
2.4
Capture and display devices ...................................................... 8
2.5
Applications ............................................................................ 8
3.
NMP Software implementations ............................................ 10
3.1
LOLA. LOw LAtency audio visual streaming system [6] ................ 10
3.1.1
LOLA main features .............................................................. 10
3.1.1.1
3.1.2
3.2
LOLA latency .................................................................... 11
Software and hardware requirements [8] ................................ 11
Ultra-Videoconferencing .......................................................... 12
3.2.1
Ultra - videoconferencing main features .................................. 13
3.2.2
Ultra-videoconferencing latency ............................................. 13
3.2.3
Software and hardware requirements ..................................... 14
3.3
JackTrip ................................................................................ 14
3.3.1
JackTrip main features ......................................................... 15
3.3.2
JackTrip latency ................................................................... 15
3.3.3
Software and hardware requirements ..................................... 15
3.4
Other developments................................................................ 16
3.5
Latency measurements ........................................................... 16
4.
Galician Network Music Performance experience .................. 19
5.
Conclusion ............................................................................. 23
6.
References ............................................................................ 24
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
Annex I. Audio interfaces .............................................................. 26
1.
MOTU 2408 mk3..................................................................... 26
2.
Focusrite Scarlett 2in2 ............................................................ 26
Annex II. Interfaces and latency ................................................... 27
1.
USB bandwidth ....................................................................... 27
Annex III. Software installation .................................................... 28
1.
LOLA setup ............................................................................ 28
2.
Ultra-video setup:................................................................... 29
3.
Jacktrip setup ........................................................................ 30
List of Figures
Figure 1. Comparison between delay time and subjective evaluation of
viewers (ref: www.itu.int)
4
Figure 2. Bandwidth requirements of different real time videoconference
systems (* approximate values)
5
Figure 3. The final configuration
19
Figure 4. FCC-City of culture physical path
20
Figure 5. Boys e Vacas distributed performance (organized by: Xaime
Fandiño, technical support: Javier Abreu, Natalia Costas, Manuel Fidalgo,
Ivelina Karagyulieva)
22
Figure 6. MOTU 2408 mk3 interface
26
Figure 7. Focuserite Scarlett 2i2 USB audio interface
26
Figure 8. Lola's main user interface
29
Figure 9. Jack Audio Connection Kit
32
List of Tables
Table 1. Bandwidth required for various video formats (25fps,
uncompressed, 24 bits/pixel, interlaced)
6
Table 2. Measurements of ping latencies between points located in research
networks
7
Table 3. Results from the latency measurements
17
Table 4. Transfer rate of the different USB versions
27
Changes history
Version Author
0.0
IAK
0.1
NCL
0.2
NCL
0.3
IAK
0.4
0.5
NCL
IAK
0.6
NCL
0.7
IAK
0.8
0.9
NCL
NCL
Description
First draft of the document for sections Introduction,
Technology Analysis, Solution, References, Annex I
(Motu and Focusrite tech. Info) and Annex II (USB
and interfaces relation to latency).
Draft’s first revision. Reorganize all sections, add
section 3.4 Latency measurements, complete
Conclusions and Experience description. Reorganize
annexes.
New complete revision of sections 2 and 3. Fixing
references.
Adding
copyright,
glossary
and
conventions.
Fixing sections 2 and 3, modification of the Annex I
and Annex III.
Review all subsections of section 2.
Fixing some of the figures.
General revision to document. Minor changes to all
sections.
Modification of Annex III. General revision of the
document.
Minor changes to Annex III and to format.
Update technical report reference identifier.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
Glossary
NMP
Network Music Performance
RECETGA
Red de Ciencia y Tecnología de Galicia (Galicia Science
and Technology Network.
CESGA
Galicia Supercomputing Centre
GARR
Italian Research & Education Network (NREN)
Geant
Pan European data network dedicated to the research
and education community
Internet2
High-performance backbone
network created
by
the Internet2 community dedicated to the research and
education community in United States. It was first
called Abilene Network.
NAT
Network Address Translation
IP
Internet Protocol
CCRMA
Centre for Computer Research in Music and Acoustics
LOLA
LOw LAtency Audio Visual Streaming System
JACK
System for handling real-time, low latency audio (and
MIDI).
Jacktrip
A system for high-quality audio network performance
over the Internet.
Ultravideoconferencing
System for high-bandwidth, high-quality, and lowlatency videoconference interaction
Conventions
This document uses several conventions to highlight certain words and
phrases and draw attention to specific pieces of information.
This icon indicates tips that could be useful for the reader.
This icon indicates important considerations that are easily
missed.
This icon indicates critical aspects that should not be
overlooked.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
Introduction
1. Introduction
A networked music performance (NMP) is a real-time interaction over
a computer/data network that enables musicians in different locations to
perform as if they were located in the same room.
While not intended to be a replacement for traditional live stage
performance, networked music performance supports musical interaction
when co-presence is not possible and allows for novel forms of music
expression.
In this work we describe the challenges that NMP introduces and also
several software implementations that make NMP possible.
We also present a practical experience based on NMP where a group
of musicians, located at geographical distant places, interact over a network
to perform as they would if they were located in the same room. Both parts
played in real-time and synchronously and the audience was located at one
of the sites and were able to listen to the resulting performance. Also low
latency video was used to allow the musicians to see each other.
This performance and tests were among locations connected to the
Galician Regional Science and Technology Network (RECETGA).
In the last section, conclusions and future work is presented.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
2
Real time distributed performance technical challenges
2. Real time distributed
technical challenges
performance
NMP is a challenging application where a number of factors influence
the audio and video quality. In this section the most relevant aspects are
analysed.
2.1 Latency and jitter
Internet, by its nature, is a network that relays on a best effort traffic
policy; this implies that there is no guarantee of quality of service end to
end to a communication specifying QoS parameters like traffic rate
(bandwidth average, peak rate, bursts duration, etc.), maximum latency
and jitter, etc. For this reason most of the music Internet tools and systems
available today require the use of pre-buffering mechanisms to avoid
running out of data and this fact makes them unsuitable for applications in
which real-time and quick interactivity is a requirement.
Research results [1] have indicated that in the case of distributed
musical rehearsals for optimal audio quality, jitter has to be kept at a
minimum and one-way latency has to be controlled at about 20ms. In [2] is
analyzed the influence in tempo of delay and it is specified that delays
≥35ms produce a deceleration in tempo that is not considered musically
acceptable. 35ms is comparable to the delay suffered by orchestra
performers separated by distances of 10m, who can maintain a steady
tempo (with a conductor).
Other important fact that affects the quality of the performance is the
perception of synchronization between audio and video. The video stream
will be delayed with respect to audio and this will also be detected by the
musicians and the audience depending on audio/video timing difference.
From [3] we can read some figures that illustrate the problem of
synchronization in broadcast systems, in particular in [4] it gives us the
detectability and unacceptability thresholds for viewer’s reception:
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
3
Real time distributed performance technical challenges
Figure 1. Comparison between delay time and subjective evaluation of viewers (ref:
www.itu.int)
From this document (Rec. ITU-R BT.1359) we get some useful
thresholds that are relevant when dealing with audio and video
transmissions:
- When the latency between the audio and video signals is in the range
from -100ms to +25ms (negative means that audio is delayed with respect
to video, and positive value means that video is delayed with respect to
audio) the user does not perceive delay.
- When the latency between the audio and video signals is in the
range from -100ms to -125ms; and from +20ms to +45ms (negative
means that audio is delayed with respect to video, and positive value means
that video is delayed with respect to audio) the user detects the delay.
When the timing difference between audio and video is bigger than
the values given before then it is unacceptable for the user.
As already stated, audio and video streams from musicians located at
different places have to be synchronized to form consistent music
presentation. For this reason various components such as the clocks of the
computers, latencies from the soundcards, capture cards and their drivers,
network interface cards, and network components, rhythm adjustments
among different players, all raise difficulty for synchronization [5]. This
requires fine tuning of all end systems and networks in the path end to end
as all these sources of variability impose many challenges in order to deploy
NMP as a service.
The one way latency should not be higher than 25-35 ms end to
end between distant locations to be considered “real time” in
music. Tests in advance are recommended to verify the effect of
latency and jitter in the performance.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
4
Real time distributed performance technical challenges
2.2 Network requirements
2.2.1
Bandwidth
High definition audio streaming is required to make a networked
music performance as realistic as possible. Transmission of mono PCM (raw)
CD-quality audio (44.1 kHz, 16 bit/sample) requires a data rate of 0.7Mb/s.
When stereo/multi-channel or high definition sound (high sampling rate e.g.
48k/96k/192kHz or better quantized e.g. using 24 bit) is needed, the
network can be further stressed.
However, real stress to network is tested when also adding video
communications to the performance. This is due to the fact that real time
systems will usually transmit uncompressed video in order to avoid the
latency introduced by compression algorithms.
The following image compares bandwidth usage of two NMP systems:
LOLA [6] and Ultra-videoconferencing [7]. The columns depict the
bandwidth needs for different (uncompressed) video qualities used by each
tool. It is shown that LOLA black&white requires less than 100 Mbps while
Ultra-videoconferencing
full-frame
uncompressed
video
requires
approximately 150 Mbps. It is also shown that the bandwidth that LOLA
requires for coloured video is almost 500 Mbps while for HD-SDI video
Ultra-videoconferencing needs at least 1.5Gbps.
LOLA b/w, 640x480, 30fps,
10bpp *
1600
1500
1400
1300
1200
1100
1000
900
800
700
600
500
400
300
200
100
0
Ultra-videoconferencing fullframe video 720x576, 24fps,
15bpp *
LOLA colored, 640x480, 60 fps,
24bpp *
Ultra-videoconferencing HDSDI, 1920x1080, 30fps, 24bpp
*
Bandwidth Mbps
Figure 2. Bandwidth requirements of different real time videoconference systems
(* approximate values)
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
5
Real time distributed performance technical challenges
Below is shown a comparison table of the bandwidth required to send
uncompressed video for different formats:
Video type
Resolution
Bandwidth
Uncompressed DVD
720x576
124Mbps
Uncompressed DV
720x576
124Mbps
Uncompressed HDV 720p
1280x720
553Mbps
Uncompressed HDV 1080p
1440x1080
933Mbps
Uncompressed HDV 1080i
1440x1080
466Mbps
Table 1. Bandwidth required for various video formats (25fps, uncompressed, 24
bits/pixel, interlaced)
2.2.2
Network traffic management for NMP
NMP applications have been deployed within research networks
(Geant, Internet2) before and, as we already stated, they are very sensitive
to latency, transmission errors, bandwidth restrictions, etc. For this reason
it is important to check several aspects related to network infrastructure:
- Analyze the path the traffic traverses as the whole path should be
adequate in terms of bandwidth, latency, transmission errors and jitter end
to end.
- Network issues might arise if the NMP traffic goes via network
equipment that is shared with other IP traffic (QoS, Bandwidth on Demand
or other automated traffic allocation mechanisms should be provided).
- Firewalls, traffic shapers and other network devices that process
traffic should be avoided as they generally introduce additional delay and
might drop packets/flows when they discover unknown protocols/traffic.
- Network Address Translation (NAT) can introduce problems even in
1:1 configuration (check with the network service support).
In summary, for NMP to be successful, the whole end to end network
path must be of very high quality and low occupation (or other traffic
allocation mechanism): low latency and jitter, error free and transparent
(no NAT if possible1).
1
At CESGA LOLA audio was tested behind 1:1 NAT successfully. In the same testlab
Ultra-videoconferencing video showed strange behavior (transmission dropped in
one way).
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
6
Real time distributed performance technical challenges
Tools like IPERF2 can help to debug network issues and check
the quality of the network connection.
2.2.3
Network latency
Network latency depends on the distance between performers and
also on the network equipment and traffic processing that is done. We will
focus on the first at the second term has to be analyzed on each particular
case.
Below we provide some measurements of ping latencies between points
located in research networks. The latency value takes into account fibre
transmission time, network equipment and also processing on end systems
(2 servers).
Location 1
Location 2
Distance
Latency
(one way)
Santiago de
Compostela
Vigo, Spain
100km
1 ms
Santiago de
Compostela
Madrid, Spain
600 km
12 ms
Santiago de
Compostela
Barcelona, Spain
1100 km
20 ms
Santiago de
Compostela
Geneva, Swiss
1500 km
25 ms
> 6000 km
Transoceani
c cable
65 ms
Santiago de
Compostela
Quebec, Canada
Table 2. Measurements of ping latencies between points located in research
networks
2.3 Servers
2
IPERF sourceforge website: http://sourceforge.net/projects/iperf/
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
7
Real time distributed performance technical challenges
Some aspects need to be taken into account when deploying NMP.
Capacity of servers should be carefully evaluated particularly when
transmitting not only audio but also video streams. In particular:
-
RAM and CPU should be enough to run seamlessly the audio/video
tools
- They should provide slots enough to accommodate the required
audio/video cards.
- Gigabit Ethernet connectivity is also a must when planning for video
communications.
- Input/output interfaces for audio/video/network should be carefully
selected
o The interfaces used to connect to the capture and projection systems
are relevant, some type of interfaces like HDMI should be avoided [8]
because of latency issues, VGA, DVI-D or RGB connectors should be used
instead. Others, like USB v1, should be avoided as they cannot cope with
the necessary bandwidth.
o Professional audio interfaces allow the end user to control the sample
rate and also the size of the buffers that are used. This last parameter can
be reduced to minimize latency. It has to be handled with care as very low
buffers can produce distortions in sound or require very high CPU
processing.
2.4 Capture and display devices
The capture and projection systems should also be carefully reviewed:
- Plasmas and LCD/LED TVs can add a big amount of latency (up to
200ms in the models tested at CESGA). Some of they can be configured in
gaming mode to avoid the processing that is done for image enhancement
and thus reducing the latency that is added.
- Additional devices, like video splitters, cable extenders, etc. might
add further latency and also affect the final result.
- Video cameras: frame rate, resolution, video interfaces
2.5 Applications
In the previous section we talked about the latency introduced by the
hardware, but this is not the only latency that eventually impacts the sound
by the time it reaches our ears, as software can also introduce latency.
Some plugins cause latency. Some computers have more, or less, latency
than others. Generally the better a computer is, the less latency that it will
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
8
Real time distributed performance technical challenges
incur on its own, but this depends on the condition of the computer, and its
load at the time. This is another reason to keep the server correctly tuned,
with the fewer processes running that can interfere with NMP software.
The last important element in the chain is the software that is
actually used for NMP. There are several software implementations for NMP
like LOLA, Ultra-videoconferencing or Jacktrip that will be explained in detail
in Section 3, “NMP Software implementations“.
What all these implementations have in common is that they try to
reduce to a minimum the internal buffers and processes that are required
for capture, audio/video signal processing and transmission/reception in
order to be fast and reduce the latency to a minimum.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
9
NMP Software implementations
3. NMP Software implementations
During the latest years several research institutions have developed
software that allows NMP and were able to conduct real-time distributed
multimedia performances in education and research networks. In this
section a summary of the most important relevant technologies and
projects are reviewed.
3.1 LOLA - LOw LAtency audio visual streaming
system [8]
Lola is a development of the “Conservatorio di Musica G. Tartini”3,
Trieste, Italy, in collaboration with GARR4, the Italian Academic and
Research Network.
LOLA’s goal is to provide a tool for real-time audio/video “natural”
distance human interaction. A special attention is paid to the optimization of
the signal processing and transmission in order to keep the system latency
as low as possible, below the human delay perception threshold.
The system is based on high performance audio/video acquisition
hardware, and on the integration and optimization of audio/video stream
acquisition, presentation and transmission.
3.1.1
LOLA main features
LOLA is an audio/video
communication point to point.
system
that
allows
bidirectional
Each LOLA node is composed by one windows server with LOLA
software installed. LOLA nodes include specific hardware for audio
capture/playback and video capture and projection systems.
The main features of LOLA are:




It allows point to point bidirectional communication
It supports multichannel audio
It supports audio devices that use ASIO interface
It supports standard definition video based
manufacturer grabbers.
Conservatorio
di
musica
Giuseppe
http://www.conservatorio.trieste.it/
4
GARR consortium: http://www.garr.it/b/eng
3
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
on
Tartini
Bitflow
(Trieste):
Act: 26/04/2014
UNE-EN-ISO 9001
10
NMP Software implementations
3.1.1.1 LOLA latency
As we can read in LOLA technical specifications, the software itself
introduces no more than 5ms to the audio and video signal.
3.1.2
Software and hardware requirements [8]
Below the main software and hardware requirements are described:
Operating system
To date, LOLA has been tested on both MS Windows XP and MS
Windows 7 (32 bits and 64 bits versions). As Windows XP is being phased
out, and Windows 7 offer better performance for LOLA, it is better Windows
7 to be used as the base operating system.
Audio input/output hardware requirements
Low latency audio performance requires that small in/out audio
buffers can be used, that no bottlenecks are present in the data transfer
between the converters and the system, and that robust and efficient
software drivers are available for the OS in use. LOLA project does not
recommend the usage of USB and FireWire (IEEE 1394) external devices as
they do not offer such a fast data acquisition processing. For this reason
LOLA uses a PCI/PCIe internal device and a reliable ASIO driver.
Video hardware requirements
Fast video acquisition and streaming relies on a family of video
grabbers by BitFlow Inc. The BitFlow video grabbers currently used by LOLA
are the analogue ones, like LOLA: Low Latency Audio Visual Streaming
System the BitFlow ALTA-AN1 grabber with SDK 5.60 drivers. It supports
both analogue b/w and colour cameras.
Cameras and projection systems
LOLA technical specification details black&white and also colour
cameras that had been tested successfully for NMP and that are compatible
with the video grabbers that LOLA supports [8].
Also low response time LED/LCD monitors are recommended.
Server requirements
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
11
NMP Software implementations
LOLA gives recommendations for minimum server configuration. The
most relevant features are the following5:
- Intel dual/quad core based on i5 or better i7 processors
- 4GB RAM minimum
- Mid/high performance motherboard with PCI Express bus and DDR3
RAM
- 1Gbit LAN port
- Integrated graphic adapter should be enough, however a PCI-Express
Video Adapter (e.g., Nvidia GeForce cards) is strongly recommended,
especially for colour video processing and for incoming GPU-accelerated
features.
- Enough PCIe free slots to host the audio, video display card and video
capture card.
Network requirements
LOLA’s bandwidth requirements come mainly from the bandwidth
usage of the bidirectional video stream.
LOLA requires at least 100Mbps in minimal uncompressed
configuration (640x480, black&white, 30 frames per second) and up to
500Mbps in full uncompressed configuration (640x480, colour, 60 frames
per second), and generates a very high Packet Per Second (pps) rate, as it
uses 1K data packets, e.g. from 100 up to 500 Kpps. Thus the minimal endto-end connectivity must be at least 1Gbps.
Port usage
LOLA uses by default ports TCP 7000, UDP 19788 and UDP 19798 for
service communication and audio/video streaming. It is thus required that
no restrictions apply for these ports (e.g. due to network or Windows
firewall settings or local network administration policies).
3.2 Ultra-Videoconferencing
Ultra-Videoconferencing is a development of the McGill University in
Montreal, Quebec, Canada. Its main focus is to develop a high quality and
low latency tool for videoconference interaction, such as that is required for
5
For a complete list of requirements please check LOLA technical specifications [8].
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
12
NMP Software implementations
high fidelity instruction, distributed musical performance and vibrosensory
data6.
Ultra-videoconferencing has been used for a range of demanding
applications including live concert streaming (1999), remote mixing (2000),
collaborative performance (2001), distance masters classes over SDI
(2002), and remote video interpreting of sign language using three
simultaneous DV streams (2003).
Ultra-Videoconferencing tool supports high-resolution multichannel
audio and video either from frame grabbers using v4l or v4l2 interfaces
(e.g., Bt878 chipset), digital video (DV) cameras, DCAM (raw,
uncompressed video) 1394 devices, and standard or high-definition Serial
Digital Interface (SDI). They are also working on mosaicing of video
displays with minimal latency and moving toward super-resolution
techniques to create video displays beyond the quality of high-definition.
3.2.1
Ultra - videoconferencing main features
The main features of Ultra-videoconferencing are:



It allows multipoint bidirectional audio and video communication
It supports multichannel audio
It supports general purpose video grabbers (standard and high
definition video)
It allows having multiple clients (multipoint communication) but not
by means of multicast technology (this implies that the streams have to be
sent to a central server). Multicast support is being implemented and it is
on its early stage nowadays (not accessible for the command line).
3.2.2
Ultra-videoconferencing latency
The measured one way end-to-end video latency is at approximately
75ms for analogue video, 100ms for DV, and 120ms for JPEG. Audio latency
can be lower than 20ms when using professional sound cards, as these
allow for minimal buffering.
6
Vibrosensory data is associated with the vibrotactile or kinematic
(motion platform) actuators to convey either mechanical displacement or vibration
to the user. Ultra-Videoconferencing has been used for transmission of additional
channels of such haptic information.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
13
NMP Software implementations
3.2.3
Software and hardware requirements
Operating system
To date, Ultra-video works under Linux (release versions have been
tested under Ubuntu and Fedora distributions).
Audio input/output hardware requirements
Regarding to audio it handles OSS and multichannel ALSA audio up to
24 bit, 96 kHz sampling.
Video hardware requirements
Regarding to video it supports high-resolution video from frame
grabbers using v4l or v4l2 interfaces (e.g., Bt878 chipset), digital video
(DV) cameras (750x576), DCAM (raw, uncompressed video (640x480)),
1394 devices, and standard ([email protected]) or high-definition (1080i60,
1080p30) Serial Digital Interface (SDI). Video can also be passed through a
JPEG codec to reduce bandwidth and the video display window may be
resized up to full screen.
Ultra videoconferencing has been tested with AJA Xena HS HD-SDI
video capture cards.
Network requirements
Full-frame uncompressed analogue video requires a minimum of 148
Mbps in the steady-state. PCM audio with default sampling (44.1 kHz, 16
bit) requires approximately 706 kbps per channel. DV camera output (audio
and video) consumes approximately 25 Mbps; JPEG-encoded full-frame
video is similar, dc1394 video at full-frame requires anywhere from 148-270
Mbps depending on colour space employed.
Port usage
Ultra-Videoconferencing uses UDP ports 8000-8010 and the helper
“uv” script uses TCP port 8000 on the server to accept incoming requests
from clients. As well as LOLA, Ultra-video should not run behind a firewall
and it should use public IP addresses (no NAT should be used).
3.3 JackTrip
JackTrip is a Linux and Mac OS X-based system used for multimachine network performance over the Internet. It supports any number of
channels (as many as the computer/network can handle) of bidirectional,
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
14
NMP Software implementations
high quality, uncompressed audio signal streaming. The technology being
used builds on early work by research groups at McGill University and
Stanford University.
It can be used between any combination of Linux and Mac OS X (i.e.,
one end using Linux can connect to the other using Mac OS X).
Currently, JackTrip uses JACK7 as its host audio server. JACK has
several advantages: it runs on Linux and Mac OS X, it has the ability to
make audio connections between many different audio clients on the same
host, and its current implementation takes advantage of multi-processor
machines.
3.3.1
JackTrip main features
The main features of JackTrip are:



3.3.2
It allows multipoint bidirectional audio (only) communication
It supports multichannel audio (as many as the computer/network
can handle)
It relays on JACK usage
JackTrip latency
No technical details for the latency introduced by JackTrip were
found.
3.3.3
Software and hardware requirements
Below the main software and hardware requirements are described:
Operating system
JackTrip supports Linux and Mac OSX operating systems.
Audio input/output hardware requirements
7
JACK is system for handling real-time, low latency audio (and MIDI). It can connect a
number of different applications to an audio device, as well as allowing them to share audio
themselves. JACK also has support for distributing audio processing across a network. [
http://jackaudio.org/ ]
140412 - DO_COM_NMP Report _v0.9.docx
Act: 8/05/2014
ENTIDAD CERTIFICADA
UNE-EN-ISO 9001
15
NMP Software implementations
16
As stated before JackTrip supports any number of channels (as many
as the computer/network can handle) of bidirectional, high quality,
uncompressed audio signal steaming.
Network requirements
JackTrip bandwidth requirement is 1-2Mbps per audio channel plus
additional bandwidth to accommodate network fluctuation.
Port usage
Each machine running JackTrip has to have the same UDP port(s)
open to run JackTrip. The default port is UDP 4464 for a two-way
connection. For projects with more than two locations, more open ports will
be necessary. Recommended ports are offset by 10, so use UDP 4474 for a
third location, UDP 4484 for a fourth location, etc. It is also recommended
to have backup ports available in case. For any project, the
recommendation is to have UDP ports 4444-4544 open.
3.4 Other developments
Other developments that are being used for NMP were found but
were not tested because of the short timeframe in which this project had to
be completed. Most of them are oriented to interactive applications
(cinema, broadcast, e-medicine, etc.) but not mainly focused on music
performance (as LOLA or JackTrip).
Among those are the following: Ultragrid (2 channel, up to 8K
resolution uncompressed and compressed to various formats, 83 ms
latency), iHDTV, DVTS and Cinegrid.
3.5 Latency measurements
During the tests some latency measurements were done, in the table
below the results are shown:
Type of test
Particular test conditions
Average
round trip
latency (ms)
LOLA audio test
between CESGA
(network 44) and
CESGA (net. 36)
1 end behind firewall, 2 hops
routing distance, integrated
audio, all traffic routed at
CESGA
18.00
LOLA audio test
between CESGA
(network 44) and
1 end behind firewall, 2 hops
routing distance, integrated
audio, all traffic routed at
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
43,29
Comments
Latency increased
due
to
LOLA
buffering to many
Act: 26/04/2014
UNE-EN-ISO 9001
NMP Software implementations
CESGA
36)
(network
CESGA, 1 end with LOLA
buffer 20, 1 end with buffer 0.
LOLA audio test
between CESGA
(network 44) and
CESGA (network
32)
1 end behind firewall, 3 hops
routing distance, integrated
audio, all traffic routed to
Lugo
(5-6
ms
additional
network latency)
LOLA audio test
between CESGA
(network 44) and
CESGA (network
32)
1 end behind firewall, 3 hops
routing distance, integrated
audio, all traffic routed to
outside
Galicia
(23
ms
additional RTT latency)
Jacktrip
audio
test
between
CESGA (network
44) and CESGA
(network 32)
1 end behind firewall, 3 hops
routing distance, integrated
audio, all traffic routed to
Lugo
(5-6
ms
additional
network latency)
LOLA audio test
between City of
Culture (network
37) and CESGA
(network 34)
Both sites behind firewall, 2/3
hops routing distance locally,
unknown routing hops at CdC,
integrated
audio,
1
way
routed to Vigo
LOLA audio test
between City of
Culture (network
37) and CESGA
(network 36)
Only CdC behind firewall, 1/2
hops routing distance locally,
unknown routing hops at CdC,
integrated
audio,
1
way
routed to Vigo
LOLA audio test
between City of
Culture (network
37) and F.C.C
(network 81)
Only CdC behind firewall, 1
hop
routing
distance,
integrated audio, all traffic
routed at CESGA
43,20
24,44
43,50
43,25
15,17
samples
Latency increased
due
to
longer
network
path
(gateway in Lugo)
Latency increased
due
to
longer
network path (to
reach
gateway
traverses a 23 ms
RTT path)
Latency decreased
using
Jacktrip
instead of LOLA.
93.60
Latency increased
due to placing one
end
at
CdC
(firewalls,
traffic
shapers, ...)
68.00
Reduced
latency
with respect to
previous
case
eliminating
firewall at CESGA
end.
40.11
Reduced
latency
with respect to
previous
case
optimizing
routing.
(1) Average roundtrip latency (maximum tolerable 50ms.)
(2) In all tests (but Jacktrip one) Ultra-videoconferencing traffic was also
traversing the devices (50 Mbps)
Table 3. Results from the latency measurements
From these tests we appreciated variations with the following sources of
latency:
-
Audio buffers (LOLA/JackTrip and audio interfaces)
Network path latency
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
17
Act: 8/05/2014
UNE-EN-ISO 9001
NMP Software implementations
-
Network devices latency (firewall/traffic shapers mainly, but also
other types of devices)
As it is shown, it is quite easy to reach the tolerable maximum value to
latency that is 40-50ms.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
18
Galician Network Music Performance experience
4. Galician Network
experience
Music
Performance
Our aim at this stage was to split a group of musicians in two
different locations and see if they were able to perform as well as if they
were located in the same room. These musicians would perform during the
event Galicia Connection’14 held in Santiago the Compostela.
Similar experiences were conducted before by research groups
involved in the development of the tools already described. We were
interested about analyzing the possibilities we had using commodity
hardware commonly available at our premises that was typically used for
videoconference and streaming purposes.
Below is depicted the configuration that we finally used:
Figure 3. The final configuration
We did a bidirectional audio and video connection between Cidade da
Cultura and Facultade de Ciencias da Comunicación with the following
characteristics:
19
Galician Network Music Performance experience
- The main setup consisted on two computers at each end. Each end
had one computer dedicated to LOLA, with an audio capture interface
connected to the venues sound system and the network and other
dedicated to Ultra-videoconferencing software with video capture interface
connected to a PAL camera, to the projection system and to the network.
- LOLA’s computers were equipped with external sound cards
(Focusrite Scarlett 2i2 and MOTU 2408 mk38, with Windows 7 OS and LOLA
version 1.2 (latest version is 1.3). Buffer settings for both audio interfaces
ware set to minimum (1ms in the Focusrite and 16 samples at a sample
rate of 44.1 samples per second at MOTU 2408).
- Ultra-videoconferencing servers were used as LOLA’s video
capabilities require specific Bitflow video grabbers that were not available.
These servers were connected to projectors by means of VGA interfaces.
Each server was dual core with 2GB of RAM with Linux Ubuntu 12.04
installed on it.
- In order to achieve further distance between both places the traffic
was routed first to Vigo (a city located 98km far from Santiago de
Compostela). With this configuration the scenario was exactly the same as if
both locations were separated 200km from each other.
Figure 4. FCC-City of culture physical path
8
See Annex I for more information.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
20
Galician Network Music Performance experience
In this case the musicians were able to perform perfectly as the audio
latency was kept under reasonable threshold.
The video latency was acceptable but still was noticeable the delay
between audio and video signals.
From this experience some hints are considered relevant:
- Previous test using video by means of H.323 videoconference devices
(based on Lifesize Express 220 platform) with HDMI interfaces showed that
delay from video with respect to audio was unacceptable. A measurement
was done showing 400ms one way delay of video.
- LOLA supports any device that used ASIO interfaces. At present most
of the general purpose audio cards work under ASIO4ALL software and, for
this reason, can be used with LOLA. We tested Soundmax integrated cards,
Soundblaster Live 5.1, Intel IDT HD Audio and Realtek integrated sound
cards. Although in some conditions they are workable (preliminary tests
were conducted successfully), some random problems arise that produce
glitches and bad effects on sound. Also the integration of unbalanced inputs
of these cards into the more professional venues sound system was
cumbersome. Changing into more quality sound cards with ASIO support
resulted in a cleaner sound and easier setup at both sites.
- Low latency PCI audio cards are preferred. In case USB is chosen
(check the latency introduced) we should take into account to connect by
means of USB2 (minimum) as the usage of USB version 1 interfaces
produced distorted audio.
- Although audio does not require much CPU consumption attention has
to be put that no processes or software interferes LOLA. CPU pikes can
produce glitches on sound. It is important to disable and avoid using any
other software that might conflict with LOLA usage.
- Due to City of Culture networking restrictions firewalls could not be
skipped on their side but time had to be invested to be sure that no traffic
was dropped. 1:1 Network Address Translation (NAT) had also a bad
influence in Ultra-video outgoing stream (from City of Culture), being the
connection dropped after the first 15-20 seconds, therefore private IP
addresses had to be routed in this case eliminating the need of NAT
translation.
- The resources of Ultra-videoconferencing showed not enough and
flickering appeared, so the video had to be sent cropped to 420x320px.
- Due to the City of Culture particular venue conditions and
conferences agenda a VGA splitter and a VGA matrix had to be added
introducing additional delay to video signal. Neither the effect of those
devices could be measured nor the delay introduced by the projector itself
because of the time constraints of the project.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
21
Galician Network Music Performance experience
- Increasing the buffer size of the audio devices did not alleviate
glitches or distortions in all the tests we did but, on contrary, it proved to
worsen the quality of the audio (for example with Scarlett Focusrite 2i2
increasing the buffering from 1ms to 5ms to 10ms).
To summarize, the musicians were able to perform successfully as
they do not need video communications to synchronize however, they need
to hear each other within a reasonable latency threshold.
Below is shown a picture of the performance as it was done for the
Galician Connection’14 during the Xornada Educa conferences.
Figure 5. Boys e Vacas distributed performance (organized by: Xaime Fandiño,
technical support: Javier Abreu, Natalia Costas, Manuel Fidalgo, Ivelina
Karagyulieva)
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
22
Conclusion
5. Conclusion
This present work is part of the analysis of the state of the art of
technology that is being developed to facilitate distributed performances
and ultra-low latency videoconferences within research networks worldwide.
These new tools will allow innovative use cases for distance music learning
and distributed performances.
In this document we described the technical efforts towards the
deployment of an environment for Network Music Performance, in which
real-time musicians interact from different locations to perform as if they
were in the same room.
All these efforts in this case had, as an objective, being able to do an
audio-visual performance within Galician Connection’14 event, this meant
that the deployment had to be made under strict time constraints (2
months) and that the difficulties had to be solved to deploy a research
infrastructure inside a production network as it is the one at City of Culture.
The performance resulted a success and further work has to be done
in order to cover more challenging scenarios and make the system easier to
deploy and adequate to be handled for nontechnical staff or with minimal
technical support.
The software that was tested worked seamlessly but it was not used
at their full capability. Further work is being done in the following areas:
 Analyze the usage of NMP in more challenging scenarios (longer
distances, multipoint performances, multichannel audio, increased video
quality).
 Analyze the complete hardware setup that is required for NMP.
 Research has been done in order to analyse the effects of latency in
performances. Although 25ms has been set a threshold for real time
performances some studies propose music compositional strategies to
maintain the perception of synchrony [9] beyond that limit.
 Evaluate/review NMP software capabilities for deployment on
production scenarios.
23
References
24
6. References
[1]
M. D. U. N. L. W. Xiaoyuan Gu, “A new networked music performance
system,” 3 12 2004. [Online]. Available: https://www.ibr.cs.tubs.de/projects/nmp/paper/nime04_networked_music_performance.pdf.
[Accessed 28 04 14].
[2]
C. C. G. L. S. T. M.Gurevich, “Simulation of Networked Ensemble
Performance with Varying Time Delays: Characterization of Ensemble
Accuracy,”
2004.
[Online].
Available:
https://ccrma.stanford.edu/~cc/pub/pdf/simNetEnsPerf.pdf. [Accessed 20
04 2014].
[3]
G. J. A. G. Patrick Waddell, “Audio/Video synchronization. Standards and
solutions. A status report.,” 300 1 2010. [Online]. Available:
http://www.atsc.org/cms/pdf/audio_seminar/12%20-%20JONES%20%20Audio%20and%20Video%20synchronization-Status.pdf.
[Accessed
12 4 2014].
[4]
ITU-R BT.1359, “Relative timing of sound and vision for broadcasting,”
1998. [Online]. Available: https://www.itu.int/dms_pubrec/itu-r/rec/bt/RREC-BT.1359-0-199802-S!!PDF-E.pdf. [Accessed 12 04 2014].
[5]
M. D. U. N. L. W. X. Gu, “A new networked music performance system,” 3
12
2004.
[Online].
Available:
https://www.ibr.cs.tubs.de/projects/nmp/paper/nime04_networked_music_performance.pdf.
[Accessed 12 04 14].
[6]
I. Conservatorio di musica G. Tartini – Trieste, “LOLA Low Latency Audio
Visual Streaming
System,” 30 1
2010. [Online]. Available:
http://www.conservatorio.trieste.it/artistica/lolaproject/documents/Lola_doc_v1.3.0.pdf. [Accessed 12 04 2014].
[7]
“McGill Ultravideoconferencing System,”
http://srl.mcgill.ca/projects/rtnm/.
[8]
1. d. m. G. Tartini, “LOLA Low Latency Audio Visual Streaming System
Installation
&
User's
Manual,”
2014.
[Online].
Available:
http://www.conservatorio.trieste.it/artistica/lolaproject/documents/Lola_doc_v1.3.0.pdf.
[9]
S. Weaver, “Latency: Music Composition and Technology Solutions for
Perception of Synchrony in “ResoNations 2010: An International Telematic
2002.
[Online].
Available:
References
25
Music Concert for Peace”,” 16 05 2011. [Online]. Available:
http://sarahweaver.org/files/weaver_masters_thesis_final.pdf. [Accessed
26 04 2014].
[10]
M. G. G. L. S. T. Chris Chafe, “Effect of Time Delay on Ensemble
Accuracy,”
3
4
2004.
[Online].
Available:
https://ccrma.stanford.edu/~cc/pub/pdf/ensAcc.pdf. [Accessed 18 04
2014].
[11]
P. Davis, “How do I use JACK over a network?,” [Online]. Available:
http://jackaudio.org/netjack.
[12]
“Jacktrip
Manual,”
[Online].
Available:
https://sites.google.com/site/jacktripdocumentation/the-team.
[13]
J.-P. Caceres and C. Chafe, “JackTrip: Under the Hood of an Engine for
Network
Audio,”
2010.
[Online].
Available:
https://ccrma.stanford.edu/~jcaceres/publications/PDFs/journals/2010caceres_chafe-JNMR-jacktrip.pdf.
[14]
“2408mk3
Overview,”
[Online].
http://www.motu.com/products/pciaudio/2408.
[15]
“USB,” [Online]. Available: http://en.wikipedia.org/wiki/USB.
[16]
“Focusrite Scarlett 2i2 USB Audio Interface,” [Online]. Available:
http://www.musiciansfriend.com/pro-audio/focusrite-scarlett-2i2-usbaudio-interface#productDetail.
[17]
“HD-CCTV,”
[Online].
Available:
http://www.webgateinc.com/wgi/eng/index.php?svc_name=content&idx=
1&amCode=C032&.
[18]
“QjackCtl JACK Audio Connection Kit - Qt GUI Interface,” [Online].
Available: http://qjackctl.sourceforge.net/.
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
Available:
Annex I. Audio interfaces
26
Annex I. Audio interfaces
1. MOTU 2408 mk3
The 2408mk3 provides 8 channels of 96 kHz analogue recording and playback,
combined with 24 channels digital I/O. Connect up to four interfaces to the included
PCI-424 card for an expanded system capable of 96 simultaneous active input and
output connections at 96 kHz.
The 2408mk3 provides cross-platform compatibility for Mac and Windows.
Figure 6. MOTU 2408 mk3 interface
2. Focusrite Scarlett 2in2
This audio interface handles 24-bit resolution at sample rates of up to 96 KHz.
It is USB powered.
It provides two microphone inputs and two line outputs. Also it provides a
monitor output that is not routed through the computer.
Figure 7. Focuserite Scarlett 2i2 USB audio interface
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
Annex II. Interfaces and latency
27
Annex II. Interfaces and latency
1. USB bandwidth
In the following table it is shown the transfer rate of the different USB
interfaces. USB 1.x is not adequate as interface for NMP performances due to its low
bandwidth support.
USB type
bandwidth
Other features
USB 1.x
1.5Mbps
(low They are usually coloured white
bandwidth)
and
12 (but some white USB ports are
Mbps (full bandwidth)
USB 2.0 compatible
USB 2.0
(Hi-Speed)
480 Mbps
They are usually coloured black
USB 3.0
(SuperSpeed)
4 Gbps
They are usually coloured blue
USB 3.1
(Superspeed+)
> 7 Gbps
Table 4. Transfer rate of the different USB versions
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
Annex III. Software installation
28
Annex III. Software installation
1. LOLA setup
These are some hints about LOLA setup, for complete installation guide please
check LOLA technical documentation [8].
System setup
To install LOLA the following steps should be followed:
 WinPcap (version 4.1.2 or later) - LOLA relies on the WinPcap windows packet
capture library, which has to be installed on the PC.
 BitFlow (SDK version 5.60) - In order to support 64 bits Windows version the
minimal SDK version must be 5.60. You do not need a license code for the BitFlow
SDK, install it as “drivers only”, when prompted for the serial number.
 Visual C++ 2010 redistributable
 LOLA package
Audio hardware setup
When LOLA is launched, it will check for all available audio ASIO devices (if
none is available, the program will provide a warning and run without audio
support). It will be possible to select the desired ASIO audio device from the Audio
Video Setup dialog window, available in the Tools menu.
TCP/UDP ports used by LOLA
LOLA will use by default ports TCP 7000, UDP 19788 and UDP 19798 for
service communication and audio/video streaming. It is thus required that no
restrictions apply for these ports (e.g. due to network or Windows firewall settings or
local network administration policies).
Running LOLA
The LOLA user interface is intended to be as simple as possible: a remote
address to call (IP address), a “Check” button to make a quick and simple preconnection test, a “Connect” and a “Disconnect” button.
Interesting features are:
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
Annex III. Software installation
29
- Local Audio test: This feature allows listening to audio that is LOCAL to the
current LOLA instance. This option is useful to debug local audio issues.
- Bounce – back Mode: This feature is useful to debug network issues. The
audio is routed to the remote site and sent back, so the complete path is tested.
- Chat Window: Since version 1.3 LOLA has a chat integrated that simplifies
communications between sites.
Figure 8. Lola's main user interface
2. Ultra-video setup:
Installing Ultra-videoconferencing
To successfully install Ultra-videoconferencing the exact release of Linux has
to be deployed. In our case we installed Ubuntu 12.04.
1. Download
Ultra-videoconferencing
http://ultravideo.mcgill.edu/download.html
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
from
Annex III. Software installation
30
2. Unpack the tarball with tar -xzf uv-<version>.tar.gz.
3. To help install the necessary support packages for various video devices and
to configure appropriate device permissions and network buffers, there is provided a
"Brontify" script that should be invoked with root privileges as follows:
sudo ./Brontify
Running Ultra-videoconferencing
This is a short collection of basic commands needed to use uv in each case:

One direction, audio and video:
server:
uv -s -x
client:
uv -s -x IP_Server
(-s sends sound; -x sends video)

Two directions, audio and video:
server:
uv -s -v
client:
uv -s -v IP_Server
(-a requests bidirectional audio; -x bidirectional video)

Two directions, specific size, sender and receiver have a PAL camera:
server:
uv -v -N p -w 427 -h 320 -W 427 -H 320
client:
uv -v -N p -w 427 -h 320 -W 427 -H 320 IP_Server
(-v bidirectional video; -N p says to use the European
PAL video norm in place of NTSC; -w, -h - selecting quarter-frame size)

Killing the processes:
killall uv
killall bronto
3. Jacktrip setup
Installing Jacktrip
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001
Annex III. Software installation
31
JackTrip requires installation of JACK Audio Plugin prior to the actual
installation of JackTrip.
As explained before, Jack is a cross platform audio routing infrastructure that
allows to route audio between different simultaneously running computer
applications. QjackCtl is a simple application to control the JACK sound server
daemon, specific for the Linux Audio Desktop infrastructure. JackTrip requires Jack
to run and expands the audio routing capabilities of Jack to include network audio
streaming.
1. Install JACK audio
-
Download and install JACK software. The package can be downloaded
from http://www.jackaudio.org
2. Install QjackCtl
- Download QjackCtl
- The installation procedure follows the standard for source distributions.
In the extracted source directory, just do:
./configure [--prefix=prefix]
make
-
and optionally as root:
make install
3. Install JackTrip
- Download
the
latest
version
of
JackTrip
on
<http://code.google.com/p/jacktrip/downloads/list>
- Choose the universal binary (unless you will be working on JackTrip
software development).
- The rest of the installation takes place in the Terminal using shell
commands
For
more
installation
details
https://sites.google.com/site/jacktripdocumentation/calendar
Running Jacktrip
a) Run Jack audio daemon
jackd -R -d alsa
b) Run Jack audio connection
qjackctl
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 8/05/2014
UNE-EN-ISO 9001
check:
Annex III. Software installation
32
c) Run jacktrip
a. as a server
./jacktrip -s
b. as a client
./jacktrip -c IP_Server
d) Verify on Jack audio connection kit that the connections are set right, as it is
displayed in the picture:
Figure 9. Jack Audio Connection Kit
140412 - DO_COM_NMP Report _v0.9.docx
ENTIDAD CERTIFICADA
Act: 26/04/2014
UNE-EN-ISO 9001