NewProduct Information

New Product Information

R/T/L/K

RX-V3200

Digital Home Theater Receiver
ToP-of-the-Line Receiver for Ultra-High-Performance Home Theater Systems. Superior Features Include Digital ToP-ART Design Concept, Quad-Field CINEMA DSP, 30 Surround Programs, SILENT CINEMA and Custom Installation Capability. Compatible with Newest Dolby Pro Logic II, DTS-ES and DTS NEO:6 6.1-Channel Movie Sound Formats.

DOLBY D I G I TA L

P R O LO G I C
The RX-V3200 is also offered with a black finish in some areas.
High-Density CINEMA DSP Circuitry
High Performance Digital Circuitry
High Quality, Wide-Range Power Amplifier
Digital ToP-ART (Total Purity Audio Reproduction Technology) is the name Yamaha has given to a design philosophy whose goal is to maximize digital quality while minimizing analog circuitry. The culmination of the best digital engineering and design possible today, it brings together several key elements to create the best-sounding, easiest-to-use A/V components available. In Yamaha Digital Home Theater Components, Digital ToP-ART can be divided into three categories.

Digital Input

Decoders: 32-Bit CINEMA DSP Original LSI (YSS-938)
96kHz/ 24-Bit DAC for 9 Channels*

Input 6-Ch

Digital Volume (099dB, 0.5dB Steps)

Processor Direct Switch

6-Channel High Output Power Main L Main R Center Rear L Rear R Rear Center

6-Ch Input

Minimal Analog Processing
* The 9 channels consist of Main L/R, Center, Rear L/R, Rear Center, Front Effect L/R and Subwoofer (LFE) channels. Front effect channel signals are mixed with main channel signals to achieve more precise separation of dialogue, music and effects on the front sound stage.
High Performance Digital Circuitry Digitally Regulated Volume Control for All Channels (Yamaha Original YAC-520 LSI) 96-kHz/24-Bit Digital-to-Analog Converters for All 9 Channels*
Digital ToP-ART Newly Developed 32-Bit Original LSI (YSS-938) for High Precision Decoding and CINEMA DSP Processing 30 Surround Programs (52 Variations) Dolby Digital, DTS Digital Surround, DTS-ES Discrete 6.1, DTS-ES Matrix 6.1, DTS Neo:6 and Dolby Surround Pro Logic II Decoding Digitally Regulated Volume Control for All Channels (New Yamaha Original YAC-520) SILENT CINEMA for Headphone Enjoyment Versatile Digital Input/Output and Custom Installation Capability Direct Access (Macro-Command, Learning and Preset Capable) Remote Control Unit with LCD Display
RX-V3200 Surround Programs: 30 Surround Programs (52 Variations) HiFi DSP Programs HALL 1 HALL 2 CHURCH JAZZ CLUB ROCK CONCERT ENTERTAINMENT Program Subtotal CINEMA DSP Programs MOVIE THEATER 1 MOVIE THEATER 2 ENTERTAINMENT CONCERT VIDEO 1 CONCERT VIDEO 2 TV THEATER ENHANCED Program Subtotal Surround Formats Hall A in Europe Hall B in Europe Hall C in U.S.A. Live Concert Freiburg Royaumont Village Gate The Bottom Line The Roxy Theatre Arena Disco 6 Ch Stereo 12 Spectacle Sci-Fi Adventure General Game Pop/Rock Opera Mono Movie Variety/Sports Enhanced 10 Dolby Digital Dolby Digital/Matrix 6.1 DTS Digital Surround DTS Digital Sur. ES Matrix 6.1 DTS Digital Sur. ES Discrete Dolby Pro Logic Dolby Pro Logic II Music/Movie DTS Neo:6 Music/Cinema 8 30

: A/V Programs

Processor Direct Switch High Sound Quality Multi-Function Processing Board, with Fully Shielded Cabinet for Reduced Digital Interference 2 High Density CINEMA DSP Circuitry New Original 32-Bit Floating-Point Quantization System LSI (YSS938) for High Precision Decoding and CINEMA DSP Processing Dolby Digital, DTS Digital Surround, DTS-ES Discrete 6.1, DTS-ES Matrix 6.1, DTS Neo:6 and Dolby Surround Pro Logic II Decoding 30 Surround Programs (52 Variations) Quad-Field CINEMA DSP for 6.1-Channel Digital Surround SILENT CINEMA for Headphone Enjoyment Virtual CINEMA DSP 3 High Quality Power Amplifier Total Low-Impedance Design High Dynamic Power, Low Impedance Drive Capability Linear Damping Finest Parts Used Throughout Wide-Range Frequency Response (10100,000 +0/-3 dB) for DVD-Audio/SACD Compatibility with High-fT Type Power Transistors Anti-Resonance, Aluminum-Extruded Heat Sink Two Direct Signal Path Output Relays Discrete Power Supply Configuration for All Channels Thick PC Board Wiring with 1.6mm Copper Jumper Cables
Program Subtotal Program Total

Remarks

Variations 12 Variations 30 Variations 10 52
A large fan-shaped hall with a wooden interior seating 2,500 in Munich. A shoebox-shaped hall seating 2,400 in Frankfurt. A shoebox-shaped hall seating 2,600. A circular hall with an expansive sound field. A large church located in south Germany. A medieval Gothic monastery located near Paris. The famous New York jazz club has a wide listening area. A popular New York club seating 300. The well known L.A. rock showcase seating 460. The sound field of a large arena. Designed to emphasize the exciting rhythms of disco music. For reproducing stereo sources via six channels.

Emphasizes the excitement of scenes with high visual/audio impact. For reproducing the expansive, supernatural effects of high-tech SF movie soundtracks. A powerful three-dimensional sound field with superb clarity. Provides clear dialogue, with a soft, expansive sound. Adds a deep, spacious feeling to video game sounds. For 2 to 6.1 channel live music sources. For 2 to 6.1 channel opera and classical music sources. For old monaural video sources. For 2 to 6.1 channel music and sports shows. A wide, all-enveloping surround sound field as in a theater.
For precise reproduction of the various movie sound formats.

: HiFi DSP Programs

: CINEMA DSP
: Tri-Field CINEMA DSP Capable
: Quad-Field CINEMA DSP Capable
RX-V3200 New Product Information
Versatile, Extensive Connections 5 Optical and 2 Coaxial Digital Input Terminals (fixed and assignable except Video Aux) 2 Optical Output Terminals (fixed and assignable) 2 Component Video Input Terminals (fixed and assignable) and 1 Monitor Output Terminal with HDTV Compatibility 6 A/V (with S-Video) and 4 Audio Input Terminals 2 A/V and 2 Audio Output Terminals Front Panel Aux Input Terminals with Optical Digital and SVideo Terminals A/V Rec Out Selector 6-Channel External Decoder Input Terminals for Future Sound Formats Pre-Main Coupler and Pre Out Terminals for Center, Rear and Rear Center Channels 2 (Mono) Subwoofer Terminals 2-Way Binding-Post Speaker Terminals (banana-plug compatible, all terminals) Custom Installation Compatibility - Zone 2 Video and Audio out for Multi-Room Control Capability - IR Port - Control Out (+12 V Trigger Out) - RS-232C Interface with Extended IR Code for Two-Way Communication between the RX-V3200 and a Touch-Pad Controller Upgrade Capability (through RS-232C Interface) for Future Sound Formats and Software
Convenient Operating Features Auto Priority Input Selection and Auto Decoder Selection Convenient Set Menu with Parameter Control Functions - Speaker Set Functions (Center, Main, Rear, Rear Center, LFE and Main Level) - Low Frequency Test - L/R Balance - Headphone Tone Control - Center Graphic Equalizer - Input Rename - I/O Assign - Input Mode - Parameter Intialize - LFE Level - Dynamic Range - Speaker Delay Time (Center and Rear Center) - Display Set - Memory Guard On-Screen Display Bass Extension Speaker A/B Selector Sleep Timer Direct-Access Remote Control Unit with LCD Display - Macro Command Keys - Learning Capability - Preset Remote Capability - Subwoofer Level Controllable High Reception Tuner 40-Station AM/FM Random Access Preset Tuning Auto Preset Tuning
Digitally Regulated Volume Control (New Yamaha Original YAC-520 LSI) Yamaha combines the best features of digital and analog volume controls with a high precision digital device (Yamaha Original YAC-520 LSI) that controls an analog signal. This provides two benefits. First, a digitally controlled device is more accurate for balancing levels between channels and offers much finer control than an analog device. The wide control range is from 0dB to -99dB, with extremely accurate 0.5dB steps throughout the entire range. This wide range and narrow steps mean that greater attenuation is possible, with precision even at low volume levels. Second, an analog volume control permits good signal resolution of low RX-V3200 vs. RX-V3000 Digital ToP-ART Surround Decoding and DSP Processing Surround Program Quad-Field CINEMA DSP Yes Dolby Digital/Matrix 6.1 Dolby Pro-Logic II DTS-ES Discrete 6.1 DTS-ES Matrix 6.1 DTS Neo:6 Digitally Regulated Volume Control SILENT CINEMA for Headphone Enjoyment Max Power Main Ch Center Ch Rear Ch Rear Center Ch Front Effect Ch Min. RMS Output Power Main Ch (8 ohms, 2020,000 Hz) Center Ch (8 ohms, 2020,000 Hz) Rear Ch (8 ohms, 2020,000 Hz) Rear Center Ch (8 ohms, 1 kHz) Front Effect Ch Digital Input Terminals Digital Output Terminals Component Video Input/Output Terminals Component Video Monitor Out Frequency response A/V Input/Output Terminals High Dynamic Power, Low-Impedance Drive Capability Dynamic Power/Ch (8/6/4/2 ohms) Linear Damping [Damping Factor (8 ohms, 2020,000 Hz)] Frequency Response Signal-to-Noise Ratio (CD) Dimensions (W x H x D) Weight

signal levels. Auto Priority Input Terminal Selection and Auto Decoder Selection Digital input terminals are provided to handle any kind of digital input. Functions are programmed to select priority in order of coaxial digital, optical digital and analog when different digital formats are input from the same source. The sound decoder is also automatically selected and processed according to the combination of the format of input signals and the selected sound field programs, while DSP sound field processing is optimized at the same time. RX-V3000 Yes Yamaha 32-Bit YSS-928 LSI 29 programs (49 variations) Yes Compatible Yes (for all channels) Yes 140 W + 140 W 140 W 140 W + 140 W 140 W 35 W + 35 W 100 W + 100 W (0.02 % THD) 100 W (0.02 % THD) 100 W + 100 W (0.02 % THD) 100 W (0.02 % THD) 25 W + 25 W (0.05 % THD) 6 optical and 2 coaxial (fixed and assignable, Video Aux: fixed) 2 optical (fixed and assignable) 2 input (fixed and assignable)/1 output (monitor) DC30 MHz 3 dB 7 input/2 output (with S-video)/1 monitor out (with S-video) Yes 140/170/220/320 W Yes [200 (main ch)] 10100,000 Hz +0/3 dB 100 dB (250 mV) 449 x 191 x 468 mm 22 kg; 48.4 lbs
RX-V3200 Yes Yamaha 32-Bit YSS-938 LSI 30 programs (52 variations) Yes Yes Yes Yes Yes Yes Yes (for all channels, Yamaha original YAC-520) Yes 165 W +165 W 165 W 165 W +165 W 165 W W +120 W W W + 120 W W (0.02 (0.02 (0.02 (0.02 % % % % THD) THD) THD) THD)
5 optical and 2 coaxial (fixed and assignable, Video Aux: fixed) 2 optical (fixed and assignable) 2 input (fixed and assignable)/1 output (monitor) DC60 MHz 3 dB 6 input/2 output (with S-video)/1 monitor out (with S-video) Yes 145/180/240/330 W Yes [200 (main ch)] 10100,000 Hz +0/3 dB 100 dB (250 mV) 435 x 191 x 468 mm 21 kg; 46.3 lbs.
RX-V3200 Digital Home Theater Receiver
RX-V3200 Extensive System Connections 6-channel external decoder input terminals Pre-main coupler, center, rear L/R and rear center preout terminals Subwoofer output terminals (mono x 2) with low pass filters Zone 2 video and audio out and RS-232C terminal for custom installation All speaker terminals are 2-way binding-post type (banana-plug compatible) *HDTV Compatible Component Video Out Frequency response of Component Video Monitor Out signal is DC 60MHz, making it compatible with HDTV monitors.

Component Video In Out

RX-V3200 Inputs and Outputs Analog In Out
PHONO CD CD-R MD/TAPE DVD D-TV/LD CBL/SAT VCR 1 VCR 2/DVR Video Aux Monitor Out
Digital Coaxial Optical In Out In Out

Composite In Out

Video S Video In Out
Fixed and Assignable Terminals Yamaha offers terminals that can be either independently assigned to sources or defaulted to fixed settings. Oil-Damped Hidden Control Panel Front Panel Aux Input Terminals with Optical Digital and S-Video Terminals: Auxiliary terminals with optical digital input make it convenient to connect a digital game machine so you can enjoy DVD games and movies.
Fixed () and Assignable () Terminals
HRTF (Head-Related Transfer Functions) Transfer functions refer to the transmission of sound to the ears and between the ears and the brain. Head-related refers to the method of measuring transfer functions by placing clinical probe microphones in the ear channels of people in anechoic chambers and recording measurements at many positions around their heads. Using these HRTF maps, Yamaha engineers were able to direct sound into the ears via headphones that accurately reproduces speaker sound from various directions. This is the basis of SILENT CINEMA. Virtual CINEMA DSP is also based on HRTF, and employs aggressive crosstalk cancellation technology. In
essence, the crosstalk signals from the left speaker to the right ear and vice-versa are cancelled and replaced by new signals that simulate rear speakers. Thus you perceive surround sound without R L C R L C actually having rear speakers.

RL RR RL RR

SILENT CINEMA Principle
Virtual CINEMA DSP Principle
Visit us at our website: http://www.yamaha.co.jp/

API54R-RXV3200@926

YAMAHA CORPORATION P.O. Box1, Hamamatsu, Japan

Clients

Direct control application
Control servers A/V Device

UPnP client

UPnP protocols

UPnP control server

Device sharing system

Device

AV/C client

AV/C control server

Figure 1.1: The intended multiprotocol network control system Chapter 5 studies each chapter of the UPnP specication in detail and considers possible methods of implementing the specication. It describes how a UPnP control server (the software which runs on the device and handles control communications on the network) for the AV receiver was designed, developed and tested. Chapter 6 examines the AV/C protocol and how an AV/C control server was designed for the AVR, and alternative ways in which it could have been designed. The development and testing of the control server and a corresponding control point application are discussed. Chapter 7 considers the need for devices to support more than one control protocol simultaneously, the issues involved in doing so, and some possible solutions to those problems. One of the methods identied was implemented in the prototype system, and this implementation is described. Automated testing veried its ability to support both UPnP and AV/C control servers at the same time.

Chapter 2

Home Entertainment Networks
This chapter examines how computer networks will cover the home, and denes home entertainment networks within those networks. The IEEE 1394 bus is proposed and evaluated as a network well-suited for building home networks.
The advent of home networks
The Digital Home Working Group (DHWG), a group of computer and consumer electronics companies promoting interoperability amongst devices on home networks, has identied three islands of computing devices in the home: the PC and Internet world, including PCs and their peripherals such as printers and digital cameras; the mobile device world, including notebook PCs, cellular phones and PDAs; and the consumer electronics, home entertainment and broadcast world. Home entertainment systems are found in most living rooms today. They are used for recreation and access to news and information by playing broadcast media, such as terrestrial, satellite and cable TV, and radio, as well as recorded media such as compact discs, video tapes and DVD discs. A home entertainment system is comprised of a number of consumer electronics devices, connected to pass media between them in analogue and simple digital formats. They include devices which are sources of broadcast media, such as radio and TV tuners, satellite and cable receivers; players for recorded media, for example, CD players, VCRs, digital video recorders, camcorders and DVD players; media outputs, such as TV sets and speakers; and a range of intermediate devices, including ampliers, AV receivers, surround sound decoders, and set-top pay-TV decoders. Many of these devices now include increasingly sophisticated computing capabilities used for controlling the operation of the devices, media processing (including tasks such as audio and video effect processing, digital video decoding and surround sound

CHAPTER 2. HOME ENTERTAINMENT NETWORKS
decoding) and user interfaces. These embedded computers could potentially be connected to a computer network. Personal computers are present in many homes. Where there is more than one PC in a home, many of those PCs have been connected by networks, to allow le and printer sharing originally, and more recently, multi-player gaming and sharing of broadband Internet access, amongst other applications. Communications systems exist for the devices within the three islands, such as Ethernet networks connecting PCs to each other and to broadband Internet access, Bluetooth networks linking notebook PCs to cellular phones, and the wide range of analogue and digital connections which home entertainment systems use. However, the three islands remain largely isolated. The DHWG envisage that the islands will converge to a single network reaching throughout the home. [1, p 3] This view is echoed by Rose and Scherf who characterise consumers current denition of home networking as sharing a broadband connection between and among multiple computers in the home this only recognises networking in the PC realm. However, they expect that a wider range of products will be connected, leading to their prediction that, in future, home networks will distribute movies and television broadcasts, music, information, enable online gaming, and send control signals throughout the home. [2, p 1] Thus the network will be used to carry the audio and video signals in streams of digitised media, instead of the variety of connections present in current home entertainment systems. ODriscoll presents a wider, more generalised approach to the topic. Recognising that there are processors embedded in devices around the home, he envisages a future in which pervasive computing will connect all devices in the home onto a network, and those networks onto the Internet, to allow communication between people at any time and place. He describes a model in which Information Appliance Networks (IANs) connect Electrodomestic Network Devices (ENDs) around the home to provide an information infrastructure that delivers Digital Media Commodities (DMCs) as well as brokering, integrated solutions and customer relationship management services to their users. DMCs are the products that people will make use of for communication, information and entertainment through ENDs on an IAN. The entertainment DMCs that he lists include TV programs, video on demand, streaming audio, gaming, text and hypermedia. [3] In another paper, Scherf classies entertainment networks into the following categories: point-to-point, a single-purpose network connection between two devices for transferring audio or video; distributed or multi-room, allowing AV signals to be transmitted from a device to a TV or stereo elsewhere in the house; and

Designed with streaming media in mind, as it provides isochronous transactions which guarantee bandwidth and regular delivery. Ability to support all applications by layering other protocols above it, including TCP/IP. Abundant bandwidth, particularly since IEEE 1394b has standardised speeds from S800 to S3200. Scalable to small embedded devices, by accommodating low-speed devices, allowing minimal implementations without unnecessary functions, and providing power over the same cable. Wireless capability using the IEEE 802.15.3 protocol adaptation layer. Ability to use a variety of cable types, which provide different lengths between nodes at different costs. Longer range cabling can be used to connect different rooms in the house. Ease of use, since the cabling uses simple connector types and the bus allows hot-plug connections, and requires no conguration. Ability to protect copyrighted content, while allowing legitimate copying using DTCP. Figure 2.3 gives a hypothetical example of how an IEEE 1394 bus could be deployed in a home and devices connected to it. The islands identied by the DHWG which would have existed before the IEEE 1394 bus connected them are shaded. Though one cannot predict which network technology will win in the marketplace, IEEE 1394 is a viable solution and able to meet the requirements of home entertainment networks. This has been conrmed by Scherf, who suggests that network-capable entertainment devices are likely to be connected with IEEE 1394 or Ethernet [4, p 4], and the DHWG, who acknowledge its value in the home entertainment cluster [1, p 7]. This work considers home entertainment devices which are attached to an IEEE 1394 bus.

Summary

This chapter has introduced home networks and the IEEE 1394 bus. From todays home entertainment systems, as well as PC and Internet systems, unied home networks will develop to include all devices. Entertainment devices will use the home network to transfer audio and video media and control, in place of the range of connection types currently in use, and are considered to form home entertainment networks.

Root device

XML Root device description

Service

XML Service description

Embedded device Service

Figure 3.2: UPnP device and service model

Control model

Control of devices is achieved through the services that it offers. The description for each service provides a detailed list of state variables, each of which represents an aspect of the state of the device, and actions which the device can perform with certain parameters. The root device description species the URLs through which each service is controlled. Thus control of the device is achieved by using HTTP and SOAP to carry an action request, or state variable value query, to the control URL for that service.

Audio Visual Control

The Audio Visual Control (AV/C) protocol is designed for the control of consumer electronics equipment via an IEEE 1394 bus.
The AV/C standards are published by the 1394 Trade Association, a non-prot organisation whose intent is to develop the market for IEEE 1394-compliant products. More than 170 companies (mostly in the consumer and audio-visual electronics industries) are members of the association. Development of the
standards is done in working groups of the association, which are comprised of employees of member companies.
An example of an AV/C-compliant home entertainment product is the Sony LISSA hi- system, which consists of CD, MiniDisc and amplier components connected by 1394 cables. The AV/C audio subunit (explained on page 23) has been implemented in the components, and commands received from the remote control and front panels are passed between the components. Crest Audio developed a prototype break-out box, the FireBoB, for connecting analogue and digital audio sources to an IEEE 1394 bus in professional studios. The FireBoB was controlled exclusively by AV/C. [21] BridgeCo provides off-the-shelf AV/C-compliant controller systems for integration into IEEE 1394attached multimedia devices, making it easy for manufacturers to incorporate AV/C control into their products. [22]
The AV/C standards are based on the AV/C Digital Interface Command Set General Specication [23]. The general specication describes how a device is modelled using the AV/C unit and subunit model, covered in detail below; and basic commands which apply to all AV/C units. The specication is itself based on the Function Control Protocol, dened in IEC 61883-1 [24], for the transport of commands and responses across the network, which in turn is based on the IEEE 1394 serial bus standard [5]. The general specication is extended by subunit specications, which dene how certain classes of functionality within a device are modelled and controlled. Examples include the audio subunit [25], which models consumer audio equipment; the panel subunit [26], for modelling a GUI display and the controls on it; and the disc subunit [27], which provides the basis for disc media models.

The HAVi specication was developed by a group of eight major consumer electronics companies. The architecture is promoted by the HAVi Organisation, a non-prot organisation which now includes a number of companies besides the founders.
Mitsubishi Digital Electronics, now a member of the HAVi Organisation, produces a range of HDTV products which are HAVi-compliant, using the NetCommand branding for their HAVi implementation. The range includes high-end rear projection TVs, such as the WS-65813 [29], which are able to receive MPEG-2 video streams via the IEEE 1394 bus and are HAVi Full AV Devices (explained on page 29). An HDTV digital video recorder, the HS-HD2000U [30], is also capable of playing and recording MPEG-2 streams via its IEEE 1394 interface, and is a HAVi Base AV device. When attached to the bus, the video recorder will appear as an icon shown on the TVs display, its interface can be presented on the TV and it can be controlled using the TVs infra-red remote control. [31]
The HAVi Specication [32] includes all specications for the HAVi Architecture, including the details of the software elements and the various functional control modules, as well as the APIs that they provide. Functional control modules are dened for tuners, video recorders, clocks, cameras, AV discs, ampliers, displays, AV displays, modems and web proxies.

Device model

The conceptual device model that HAVi uses is composed of devices and functional components. Each physical unit is represented as a device, while different aspects of the device that can be controlled are

Functional component

Functional component Device
Figure 3.5: HAVi device and functional component model represented as functional components. Both devices and functional components use plugs (based on IEC 61883-1 concepts) to represent the end points of connections, where sink plugs receive input and source plugs provide output connections. The model is illustrated in gure 3.5.

Software model

The HAVi architecture introduces a model of software objects, each of which provides a service, that interact with each other to provide HAVis control applications. The objects are termed software elements and are identied by unique software element identiers. Software elements register themselves with the Registry, itself a software element. They communicate with each other by passing messages via the Messaging System software element, which acts as a hub for the messages. The message passing system is able to deliver intra- and inter-device messages, thus software elements need not be aware of whether the elements with which they communicate are local or remote.

Figure 4.2: rxvqt user interface on the tuner, which can only be set on the front panel of the AVR. Future devices which are designed to be controlled across a home entertainment network should allow control of as many aspects as possible remotely. The state variable model allows one to consider the functionality of the AVR more clearly than can be seen from the list of commands in the RS-232 protocol specication. The list of variables represents the functionality in a simple form before one attempts to apply the conceptual model of a control protocol to the device.

Controlling the RX-V1000

An application which controls the AVR was developed for purposes of testing RS-232 control and designing a user interface to represent the AVR. rxvqt runs on a PC connected to the RX-V1000s RS-232 port. Its user interface (shown in gure 4.2) shows the current state of the AVR and allows the user to control it. rxvqt is written in C++ and uses the Qt 3 toolkit. Qt provides cross-platform GUI and application support classes [37], so rxvqt has been used on FreeBSD and Linux systems and could be compiled for use on other platforms, including Windows and Mac OS. A thread receives report commands from the AVR through the serial port. It uses functions from librxv (see section 7.5) to parse the RX-V1000 RS-232 format, then updates the user interface controls to reect the current state of the device. rxvqts communication with the AVR is normally through the serial port, but can also be through the programs standard input and output le descriptors (stdin and stdout) so that it can be used with the splitrxv and
simrxv virtual RX-V1000 simulators introduced in sections 7.5 and 7.6. When the user alters controls on the user interface, rxvqt sends the appropriate command to the AVR to effect that change on the device.
The Yamaha RX-V1000 AV receiver is an example of a device commonly found in home entertainment systems. It provides an RS-232 serial port which allows remote control of the AVR, and makes it well suited for the development of a prototype network controlled device. The serial control protocol includes control commands which allow controllers to change the state of the device, and report commands which indicate the current state. A state variable list has been drawn up to represent the controllable functions of the device in a simple manner. The rxvqt application allows a PC to control the AVR. The following chapter examines UPnP in detail, based on experience gained during the development of a UPnP control server to control the RX-V1000.

Chapter 5

Implementing Universal Plug and Play
A working implementation of the UPnP Device Architecture version 1.0 specication [16] was created to allow a UPnP control point to control the Yamaha AVR. An overview of the system is presented, and the details of each of the six chapters of the UPnP specication and the implementation of each chapter are described in this chapter.

The implementation of the SOAP HTTP binding requires an HTTP server on the embedded system which is capable of generating dynamic responses based on the execution of an action, rather than merely
soap_request serviceType v actionName error type args

soap_arg name value next

Figure 5.6: SOAP request data structure the retrieval of les required by the previous chapter. The parsing of SOAP XML messages is more complicated and must be more exible than the parsing of a binary data structure. These increase the amount of program code in the embedded system and the demands placed on the CPU. Since the sizes of the SOAP messages received and sent vary, it is easiest to allocate memory dynamically, which makes peak memory use unpredictable unless message size limits are set.
From the perspective of the network, the control protocol appears to be nothing more than HTTP requests and responses, and, as noted in section 5.6, HTTP can be carried over an IEEE 1394 bus without problems.
The SOAP server was rst developed as a CGI (Common Gateway Interface) program which was called by the Apache HTTP Server to handle HTTP requests to the control URL. This allowed development to focus on the SOAP protocol by allowing Apache to handle the HTTP protocol. A soap_request structure (gure 5.6) is used to track the state of each request, including the request type, an error code, and the list of in- and out-parameters. After each requests HTTP headers are checked, the SOAP envelope is parsed. The soap_parsexml function uses the expat XML parser toolkit [54] to parse the XML document. While many SOAP-handling and XML-parsing libraries are available, expat was selected as it is: available under a liberal open-source licence, which allows it to be included in commercial products; written in C, like the rest of the UPnP implementation, which simplies compilation and linking; very fast, proving to be twice as fast as its nearest competitor in a benchmark test [55]; and small, making it suitable for use on an embedded computer. Either expat version 1.2 or 1.95 can be used since the parsing required is simple enough to not rely on any of the functionality

Separate HTTP server design, as implemented: TCP port 80

httpd UNIX pipe

TCP port 2002

soaphttpd

rxvupnp
Figure 5.7: SOAP service designs system. The controller was a Perl script which used the HTTP::Request module from the LWP (Library for WWW in Perl) to send three different SOAP requests to the control server, and high-resolution timing facilities from the Time::HiRes module to measure total time elapsed. The requests were a badlyformatted SOAP request to test error handling; a queryStateVariable action to retrieve the value of a single state variable; and a getallvariables action to retrieve the values of all state variables. Each request was sent ten times with a one second delay between each run, and each time the SOAP server would parse the request, query rxvupnp for the variable values, format the response and return it to the controller. Note that this included no serial communication with the AVR, as the aim was to determine how much time the control communication took. The FireSpy400 was used to measure the time elapsed between the time the rst IEEE 1394 frame of the request reached the bus, and the time that the last frame of the response was transmitted on the bus. The controller script recorded the total round trip time by timing how long the request() function took to return, which is the time that a real controller might wait. The results of the rst runs were found to be inconsistent with the subsequent runs, so they were discarded, and the results in table 5.1 reect the last nine runs of each test. Possible causes of the slow times of the rst runs were the initial ARP queries, the results of which would be cached in the machines ARP tables for the remaining runs; and the operating systems scheduler increasing the control servers priority from idle. The complete result set appears in section D.1. The times for the rst and second tests are similar, even though in the rst case there was no need to query rxvupnp, and the error response is longer than the single variable response. The third test takes substantially longer to process, as its response includes the values of more than 40 variables. There is a
CHAPTER 5. IMPLEMENTING UNIVERSAL PLUG AND PLAY Time on the bus (in ms) Min Avg Max Std dev 4.216 4.283 4.591 0.116 4.253 4.279 4.296 0.015 5.673 5.693 5.717 0.017 n = 9 for all tests Table 5.1: Results of soaphttpd performance testing Round trip time (in ms) Min Avg Max Std dev 6.233 6.307 6.806 0.188 6.254 6.285 6.306 0.017 7.682 7.711 7.736 0.019

Test Invalid request queryStateVariable getallvariables
consistent difference between the time measured by the bus analyser and that measured by the controller of almost approximately 2 milliseconds. This time would be taken by processing performed on the controller PC by the TCP/IP stack in the kernel and the Perl HTTP classes.
The SOAP programs could make better use of memory. The arguments list, argument values and response document are created using dynamically allocated memory, which could be exhausted by a sufciently large request to a small embedded system. The functions could be redesigned to use static memory, or limits placed on the size of input the programs will accept. The HTTP handling functions in soaphttpd dont handle mandatory HTTP headers as strictly as the HTTP Extension Framework dictates, and the XML parsing functions dont necessarily follow the SOAP Processing Model in the SOAP standard [19, section 2]. However, xing either issue would increase code size and make the programs less exible about the input they accept. The expat library could be shrunk further. At present, even when compiled using the reduced code size option, expat adds at least 52 kilobytes to the executable (using the GCC 3.2 C compiler for Linux on the x86 architecture). XML-parsing functionality not used by soap_parsexml could be pared from expat to reduce the amount of memory used and possibly improve processing speed.
Measures could be taken to reduce the command-response latency. Points which could be addressed are the network latency and processing latency. Approaches to reducing the rst should attempt to avoid establishing a TCP connection per control action or query. That could be done using a connection-less protocol such as UDP, though the limits that would place on message size would be unacceptable; or the use of persistent HTTP connections, as HTTP version 1.1 allows TCP connections to be kept alive for multiple HTTP transactions [50, section 8.1]. Thus each control point would only need to open a single TCP connection to the device for its control purposes.
The Web Services Description Language (WSDL) [56] is used to describe web services which use SOAP over HTTP, and is used by development environments such as Microsoft Visual Studio.NET. Devices could publish WSDL descriptions of their control services in addition to, or instead of, the UPnP chapter 2 service descriptions to allow programmers easier access.

UPnP chapter 4: Eventing

Eventing refers to the process by which a control point is informed of events that change the state of a state variable in a device it controls. For example, if a device supports eventing on a volume state variable, control points can be notied of the new volume level when the volume knob is turned. Chapter 4 of the UPnP specication describes a publisher/subscriber model in which each service that has evented state variables is published by the device, and control points may subscribe to that service to receive events. Services that support eventing specify an event subscription URL and mark each state variable as evented or not in their service descriptions. Subscribers may subscribe to receive notication of a services events, renew that subscription before it expires, or cancel it to stop receiving events. Publishers send event messages to subscribers. Subscription and event messages are communicated using HTTP augmented with General Event Notication Architecture (GENA) [20] headers, and state variable values are formatted according to the UPnP event XML schema in the event messages. A control point can open a subscription to receive event notications for a certain service by sending a SUBSCRIBE HTTP request to the eventing URL given in the service description, indicating how long the subscription should last (the timeout) and the callback URL on the control point to which event messages should be sent. If the subscription is accepted, the publisher will send a response with a subscription identier (SID) and the agreed timeout. As soon as possible, the publisher will send an initial event message in a NOTIFY request to the callback URL for the subscription. The body of the initial event contains the current values for all evented state variables in the service. When state variables change afterwards, the publisher will send event messages with new state variable values. All event messages include a sequence number, incremented for each event message to allow the subscriber to detect missing or out of order messages. No means is provided for subscribers to request retransmission of missing messages, short of cancelling and reopening the subscription to force another initial event message. Sometime before the timeout length has passed, the subscriber must renew its subscription or the subscription will lapse. This is done by sending another SUBSCRIBE request, this time including the SID of the subscription to be renewed. Subscriptions can be explicitly cancelled by sending an

The presentation page is only able to receive state variable values by polling the SOAP interface. Implementing an eventing subscriber would allow the page to be continuously updated. This could be done by incorporating a subscriber API in the browser or writing a browser plug-in that could be downloaded from the device.
Figure 5.15: Presentation page for the RX-V1000
While the presentation chapter could be greatly expanded to a complete user interface system, such as the AV/C Panel Subunit, there is justication for the current, non-specic chapter. Firstly, the current specication matches UPnPs goals, given in the Device Architectures introduction: Universal Plug and Play is a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, ofce, and public spaces. [16] The Addressing, Discovery and Description chapters achieve proximity networking, and the Control and Eventing chapters describe standardised protocols to allow devices to interact with each other, but the user interface is not mentioned. Secondly, many existing devices already have their own control web pages, which, given the openness of the specication, can now be easily incorporated into a UPnP compliant device. Thirdly, this allows for competition between vendors and differentiation between their products.
genapub state changes rxvthread device state queries, actions responses soapthread rxvupnp

RX-V1000

Figure 5.16: rxvupnp data ows
Coordinating the UPnP control server: the rxvupnp program
The last part of the UPnP implementation is the rxvupnp program which starts the ssdpd, soaphttpd and genapub programs, and proxies their communication with the AVR. rxvupnp is the only part of the implementation which has specic knowledge of the RX-V1000s RS-232 control protocol. It links in the librxv library (covered in greater detail in section 7.5) and uses its functions and constants to format action commands and parse report commands. As it understands the RX-V1000 control protocol entirely, it is able to attach to the AVR directly, communicating via the serial port device; or through splitrxv (covered in section 7.5), communicating via stdin and stdout. Since they are independent of the RX-V1000 control protocol, the other programs (i.e. ssdpd, soaphttpd and genapub) can be recongured and reused to create a UPnP implementation for an entirely different device. rxvupnp splits the communication between the AVR and the UPnP protocol programs into channels allowing the programs to be implemented as separate processes which can be developed and tested independently or replaced. rxvupnp is implemented as two threads, shown in gure 5.16: one which waits for input from the AVR; the other for input from soaphttpd. Since the current genapub program only requires unidirectional communication, no thread is required to listen for input from it. Similarly, ssdpd only needs to be started and requires no communication with rxvupnp. The RX-V1000 thread receives report commands, updates rxvupnps copy of the state of the device, and passes an event notication to genapub. The SOAP thread receives queries and actions from soaphttpd, answering queries from its record of the device state, and passing actions towards the AVR. Queries must be answered from a copy of the device state since the RX-V1000 serial control protocol provides no means of querying the values of specic state variables. Synchronisation measures used are a mutex to prevent simultaneous reads and writes to the device state, and a binary semaphore which the SOAP thread waits upon when it sends a command. The RX-V1000 thread signals when the result of that command is received.

Testing the system

The combination of the AV/C and UPnP control servers and splitrxv was tested to verify that control instructions and change notications ow across the system. The tests aimed to provide automatic and systematic validation of control and notication delivery throughout the system, rather than measure performance, as each control servers performance was measured in isolation in the previous chapters. Based on the model of section 7.2 and requirements of section 7.3, the tests veried in a practical manner that changes entering the system from any source notied all event subscribers and updated all copies of the device state. A Perl program, verify.pl, oversaw the tests using a simulated RX-V1000 and a set of AV/C and UPnP clients on the device- and client-sides of the control servers respectively. Both the control server and testing software were run on a single PC to give verify.pl access to both sides of the control server system. The components and interactions of the test system are diagrammed in gure 7.4. All of the programs shown in the Control Servers section were under test, the programs in the rest of the diagram performed the tests.

The RX-V1000 simulator

A software simulator of the RX-V1000, named simrxv, was developed. The simulator maintains a model of the AVR, and accepts commands in the RX-V1000 format and responds in the manner that the AVR itself would. Thus it is capable of communicating with the splitrxv sharing layer, or directly with the rxvavc or rxvupnp control servers, or the rxvqt controller. In the test scenario, simrxv provides a precisely controlled and monitored source of event notications to the control servers and destination for commands from them. The simrxv program provides a simple command line interface through which the values of state variables can be queried and changed. The command line interface is equivalent to the front panel of the real AVR which displays its state on an LCD display and where its buttons change the AVRs state.

verify.pl

soaphttpd rxvupnp genapub simrxv state RXV splitrxv state UPnP control server

soapcli.pl

genasub.pl

rxvavc state

avccli

Control servers

Figure 7.4: Control server testing system simrxv starts a program and communicates with it using the RX-V1000 serial format through its stdin and stdout. Thus the RS-232 port on the RX-V1000 corresponds to a pair of UNIX pipes in simrxv. For each control command received through either interface, simrxv updates its state model, sends the appropriate RX-V1000 report command, and prints the name and new value of the variable on the command line interface. Though the RX-V1000 format does not provide a means to query state variable values, queries received on the command line are answered based on the values in the state record. A real RX-V1000 could be used for testing, but verify.pl would not be able to control it itself, so a human test operator would need to press front panel buttons at the appropriate times and conrm that the AVRs state had changed. simrxv allows fully automatic testing of the control server software, reducing the time taken to run the tests and eliminating the possibility of human error.

This chapter has considered the simultaneous use of multiple control protocols to control a device. There are practical reasons why it would be an advantage for manufacturers to support multiple control proto-
CHAPTER 7. SYNCHRONISATION test sent recv recv recv recv recv recv recv sent recv recv recv recv recv recv sent recv recv recv recv recv recv recv run 0 "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-53.0" "volume=-75.5" "volume=-75.5" "volume=-75.5" "volume=-75.5" "volume=-75.5" "volume=-75.5" "volume=-75.5" "volume=-56.5" "volume=-56.5" "volume=-56.5" "volume=-56.5" "volume=-56.5" "volume=-56.5" "volume=-56.5" "volume=-56.5"
to soapcli from soapcli; OK from genasub; OK from simrxv; OK from avccli; OK from avccli; OK from simrxv; OK from soapcli; OK to simrxv from genasub; OK from avccli; OK from simrxv; OK from simrxv; OK from avccli; OK from soapcli; OK to avccli from avccli; OK from genasub; OK from simrxv; OK from avccli; OK from soapcli; OK from avccli; OK from simrxv; OK Figure 7.5: Test results from verify.pl
cols in a single device, and they should be supported simultaneously. However, this is not necessarily easy and calls for time-multiplexed access to the host CPU in the device. An examination of a model of the scenario revealed that solutions to the problem must synchronise the state of the device across the system and manage the control of the device. Synchronisation can be achieved by ensuring that fast, reliable paths exist for state change notications to reach all copies of device state whenever a state change occurs from any source. Control commands must not be allowed to overlap, and should be kept from conicting. Four possible methods of synchronisation were discussed. A polling system would be simple to implement, but might not be able to keep all parts of the control system synchronised. Virtual copies of the device could be simulated, one for each of the control servers to interact with. A high-level function interface could provide a level of abstraction from the devices native control protocol. Protocolconversion bridging could allow a control server to be implemented as a client of another control server. The splitrxv program implements the virtual device simulation approach for the RX-V1000. librxv provides a common library of functions for formatting and parsing communications to and from the AVR.

UPnP GENA tests

Delivery of GENA event notications
Run Minimum Average Maximum Standard deviation Latency 2.647000 2.699000 2.641000 2.610000 2.685000 2.631000 2.566000 2.666000 2.643000 2.584000 2.566000 2.636111 2.699000 0.044228

ICMP ping test

Run 9 Minimum Average Maximum Standard deviation Round trip time 0.139 0.130 0.140 0.137 0.128 0.144 0.142 0.123 0.142 0.123 0.136 0.144 0.007339

AV/C status tests

Unit status command
Run First frame Last frame 0.606730 1010.235575 2020.227905 3030.240967 4040.234558 5050.266622 6060.267843 7070.267700 8080.274943 9090.271423 Time on the bus 0.606730 0.507161 0.497090 0.503032 0.494303 0.519063 0.514323 0.502136 0.512248 0.503906 0.494303 0.505918 0.519063 0.008098 Round trip time 0.659000 0.544000 0.529000 0.538000 0.525000 0.552000 0.547000 0.541000 0.542000 0.533000 0.525000 0.539000 0.552000 0.008689 Difference 0.052270 0.036839 0.031910 0.034968 0.030697 0.032937 0.032677 0.038864 0.029752 0.029094 0.029094 0.033082 0.038864 0.1009.2019.3029.4039.5049.6059.7069.8079.9089.767517 Minimum Average Maximum Standard deviation
Function block status command
Run First frame Last frame 10100.311910 11110.323629 12120.323771 13130.362671 14140.330098 15150.354655 16160.364909 17170.355428 18180.351379 19190.376851 Time on the bus 0.535238 0.537903 0.537720 0.568604 0.530822 0.538310 0.554260 0.540609 0.529988 0.548929 0.529988 0.543016 0.568604 0.012332 Round trip time 0.569000 0.573000 0.568000 0.602000 0.562000 0.582000 0.586000 0.572000 0.562000 0.582000 0.562000 0.576556 0.602000 0.012875 Difference 0.033762 0.035097 0.030280 0.033396 0.031178 0.043690 0.031740 0.031391 0.032012 0.033071 0.030280 0.033539 0.043690 0.10099.11109.12119.13129.14139.15149.16159.17169.18179.19189.827922 Minimum Average Maximum Standard deviation

AV/C notify tests

Delivery of Changed response
Run Minimum Average Maximum Standard deviation Latency 0.017000 0.102000 0.065000 0.023000 0.100000 0.051000 -0.004000 0.103000 0.057000 -0.002000 -0.004000 0.055000 0.103000 0.042444

Appendix E

Contents of the CD-ROM
The accompanying CD-ROM contains the source code for the software written for this project, and this thesis in LYX and PDF formats. The directory structure is listed below, with cross-references to the sections of the thesis that describe the programs. Section /cvs/ /src/ CVS repository. A checked-out copy of the contents of the CVS repository. The software can be built on a FreeBSD or Linux system using the makeles in this directory. avcqt/ AV/C controller for the RX-V1000 AV/C control server. Requires Qt 3 and libraw1394, thus can only be built on Linux. description/ dumps/ UPnP XML description les and HTML presentation page. Captured examples of the RX-V1000 RS-232 format and SSDP transactions. exp/ genapub/ librxv/ rxvavc/ Experimental code. UPnP GENA eventing server. Library for formatting and parsing RX-V1000 commands. AV/C control server for the RX-V1000. braw1394. rxvqt/ Graphical application for controlling an RX-V1000 via RS232. Requires Qt 3. rxvupnp/ UPnP control server coordination program for the RXV1000. simrxv/ Software simulator of the RX-V1000. 7.6 5.10 4.4 Requires li5.8 7.5 6.1 5.6 6.8