Implementing AES-64 Control for Ethernet AVB

James Dibley and Richard Foss

Department of Computer Science Rhodes University Grahamstown 6140 Email: g11d3593@campus.ru.ac.za, R.Foss@ru.ac.za

AbstractAES-64 is a standard for discovery, enumeration, connection management and control of multimedia networks. This paper discusses the implementation of AES-64 control on Ethernet AVB audio streaming devices based on the XMOS XS1 family of microcontrollers. Index TermsAES-64, converged services, Ethernet AVB, Ethernet Audio Video Bridging, multimedia, media networks, XMOS, XS1

II. T HE AES-64 STANDARD The Audio Engineering Societys AES-64 standard1 denes a scheme for representation of multimedia network devices, a peer-to-peer protocol for device-to-device communications, and a series of high-level control mechanisms for automating common audio engineering tasks. The standard was ratied in 2012 [5]. The AES-64 standard has been shown to provide control and management of multimedia devices on IEEE 1394 audio networks. AES-64 has been used to implement connection management between emulated Ethernet AVB multimedia devices, and to simultaneously manage connections between emulated Ethernet AVB and IEEE 1394 media networks [6] [7]. It was of clear interest to the AES-64 project to develop the representation and control of Ethernet AVB devices. One major difculty was the shortfall of available Ethernet AVB devices for research and development: Ethernet AVB devices required signicant extensions to the standard Ethernet media access control (MAC) component. Until quite recently, implementations have been scarce. The XMOS Ethernet AVB reference design provided a direct solution to this problem. This open-source reference design implements an Ethernet AVB streaming audio endpoint [8] on hardware using the XMOS XS1 family of microcontrollers, including the XMOS/Attero Tech AVB Demo Board [9]. The XS1 microcontroller implements an event-based architecture designed to support deterministic multithreaded programs, including low-level hardware interfacing, and have enabled the software-dened implementation of an Ethernet AVB-compatible MAC component. The decision was taken to develop a new implementation of an AES-64 protocol stack and control application, providing the opportunity to evaluate the XMOS architecture as a platform for development of audio control protocols and applications. Control standards for audio distribution networks can be characterised in terms of three critical commitments:

I. I NTRODUCTION Applications of audio distribution technology are diverse and widespread, including live performance, broadcasting, recording facilities, as well as the sound reinforcement systems provided in public buildings, public transport, etc [1]. These temporary or permanent installations are typically based upon point-to-point data links between a large number of devices. This dependency on point-to-point links makes dynamic reconguration of the installation difcult, limits the opportunities for monitoring system performance, and makes it challenging to provide system redundancy, resilience or scalability. Audio distribution networks promise to remove many of these restrictions by providing a networked transport system for audio applications. Proprietary forms of this technology have been in service since the mid-1990s. However, the IEEEs Ethernet Audio/Video Bridging (Ethernet AVB) project has recently provided a standardised audio distribution technology [2] that extends the provisions of the IEEE 802.1Q VLAN standard [3] [4]. It is capable of transporting audio/video over bridged local area networks while simultaneously allowing and shaping conventional data trafc. A mature standard for control, monitoring and connection management is a clear prerequisite for research and development of audio applications of this technology. This paper describes the implementation of a protocol stack and control application for one such standard AES-64 on Ethernet AVB endpoint devices based on an open-source Ethernet AVB implementation.
This work was undertaken in the Distributed Multimedia CoE at Rhodes University, with nancial support from Telkom SA, Tellabs, Genband, Easttel, Bright Ideas 39, THRIP, Universal Media Access Networks GmbH and NRF SA (UID 75107). The authors acknowledge that opinions, ndings and conclusions or recommendations expressed here are those of the author(s) and that none of the above mentioned sponsors accept liability whatsoever in this regard.

representation of devices and their functional composition

1 The standard was previously named AES-X170, and prior to that XFN.

messaging addressing device representations, dening a command lexicon, facilitating autonomous machine-tomachine interaction control mechanisms encapsulating common control operations (establishing inter-device relationships, bulk retrieval of device conguration, etc.) An account of AES-64s approach to each of these follows2 .

address, a device node ID, and a valid full address block. Alternatively, once a controller has enumerated the target device, it may address requests to individual parameters by providing a parameters unique identier, which bypasses the level hierarchy to locate it within the parameter array.
TABLE I AES-64 FULL ADDRESS BLOCK Identier Type Section Block Section Type Section Number Parameter Block Parameter Block Index Parameter Type Parameter Index Value DEVICE_INFO_CONFIG INTERFACE_CONFIG 1 IP 1 IP_ADDRESS 1

A. Representation AES-64 provides a representation scheme designed to express the functional composition of a device in a clear, readable structure that supports efcient enumeration and command addressing. The fundamental unit of representation in AES-64 is a device node, which encapsulates the entire functionality of a device3 . The device node is a container for (a) an array of device parameters, and (b) a level hierarchy. Each device parameter holds a set of attributes that are declared and congured by the devices control application. These attributes can be addressed and manipulated by the control application (e.g., in response to a HCI event) and by AES-64 messages from remote hosts. The most signicant attribute is the parameter value, which takes one of a number of standardised formats. Device parameters fall into two broad classes: display parameters, which display (to AES-64 messages) an operating state or condition on the device, and control parameters, which can be manipulated by AES-64 messages to enact control over device operations. The control application must declare each parameter with a value function attribute. The value function must be supplied by the application, and may dene different actions for a get or set interaction (although a display parameter will only dene a get action). The level hierarchy depicts the devices structural organisation. Audio devices have inherently complex structures, as: they are capable of processing a number of related-butdiscrete signals simultaneously i.e., a device will typically have multiple instances of functional components like input and output channels. a functional component (e.g., an input channel) will often itself be composed of instances of smaller functional components (one or more amplier stages, one or more equaliser stages, groups of insert points or bus sends) A level hierarchy enables each parameter within a device representation to be uniquely located within (a) multiple instances of a functional component, and (b) the structural composition of an individual instance. The position of a parameter within the level hierarchy is declared as a sequence of seven numeric identiers (a full address block). AES-64 request messages may target one or more parameters on a device by providing a device network
2 The following discussion presents the output of requirements analysis conducted during the course of the research [10], and is not merely a summary of the published standard. 3 AES-64 does support representations that use multiple device nodes, which can be useful to represent a device that forms a gateway e.g., between two transport mediums.

B. Messaging AES-64 messages are either requests or responses. All AES64 messages provide a network header that expresses the target device address, target device node, source device address, source device node and source parameter ID. Beyond this base header, AES-64 message headers may vary depending on: whether the message is a request or a response whether a request expects the target to respond whether a request targets a parameter or a device node how a request addresses its target In all cases, the message header is followed by a value eld. The contents of the value eld are command-specic (in the case of a response, specic to the command that instigated the response). Most messaging exchanges in AES-64 are straightforward. In the basic case, a request targets a single parameter or a device node. The request may optionally expect the target to issue a response, which might be a command-specic return value or a simple acknowledgment. More advanced messaging cases exist, but are beyond the scope of this paper. C. Control mechanisms AES-64 also provides control mechanisms to support efcient inter-device operations. A prominent example is the parameter relationship, or join mechanism. The join mechanism provides control grouping that links AES-64 parameters within a group. Conventional audio mixing consoles implement equivalent mechanisms to manage groups of related signals - for example, a set of eight input channels that are carrying signals from microphones stationed on a single drum kit may have the level faders or mute buttons linked so that a change to one channels control is applied to all of the channels. Chigwamba et al. describe the origin of this mechanism in the control grouping facilities found in conventional audio mixing consoles [11, pp. 133-135] and survey the emulations found in other audio network control protocols (including OSC, ACN, etc.), establishing the following requirements for an AES-64 implementation:

The need for a standard network-wide grouping mechanism to allow for consistent parameter relationships across audio networks; The need for relationships between parameters that reside on different devices; The need for relationships between parameters with unrelated units, for example, a synchronized change of gain and pan parameters; The need for an efcient mechanism that allows for event driven single-target or multi-target messaging. [11, p. 139] A detailed discussion of the AES-64 parameter join mechanism is beyond the scope of this paper, and Chigwamba et al. provide a comprehensive account, including use cases. However, accurate implementation of the join behaviour dened in the AES-64 standard was determined to be a mandatory requirement for the implementation of an AES-64 stack. The join mechanism is particularly signicant in that it introduces the idea of uninterruptible actions to the AES-64 stack. In order for a device parameter to process a join request, the device parameter must query the status of at least one other parameter, receive a response, and send follow-up requests to an indeterminate number of other parameters, before acknowledging completion to the origin of the join request. The join request initiates alterations to the states of multiple parameters (possibly multiple devices), and interruptions will produce undened behaviour. As such, any unrelated inbound AES-64 messages must be queued while an uninterruptible request is being processed, unless the stack is able to process unrelated messages in parallel. III. D ESIGN The analysis and design process employed in this research has been covered at length in an earlier paper [10], but a summary discussion follows. The decision was taken to apply existing analysis and design methods appropriate to real-time systems, in the interest of evaluating the congruence of these methods with the features of the XS1 architecture and the XC programming language. A. Real-Time Structured Analysis and Design (RTSAD) This method, presented in [12], focuses on producing a comprehensive specication of the problem space, excluding any implementation details (e.g., characteristics of the intended target hardware/operating system, communication protocols, etc). It produces a behavioural model, which forms a complete requirements specication for the intended system, and an essential model that forms a structured specication in terms of data composition, data ows, and data transformations of how those requirements must be met. B. Design Approach for Real-Time Systems (DARTS) The DARTS method [13] aims to provide an approach for structuring the system [as specied through Structured Analysis and Design] into tasks as well as a mechanism for dening the interfaces between those tasks.

Fig. 1. Implementation model, structuring an AES-64 protocol stack and control application into concurrent tasks. Data ows have been bundled and some interactions omitted for clarity. The Device Control Thread represents the task that co-ordinates the operation of the entire Ethernet AVB endpoint.

Besides providing straightforward and clear criteria for structuring the RTSAD essential model into an implementation model (Fig. 1 shows a simplied-for-print version), the DARTS method was found to be highly appropriate for development on the XMOS platform. The DARTS formalisation of task interfaces maps closely to the XMOS idioms for synchronisation and communication between concurrent processes: the DARTS Task Synchronisation Module corresponds directly to the XC select keyword, while the types of communication supported by the DARTS Message Communication Module can all be implemented straightforwardly using XC channels. IV. I MPLEMENTATION A primary goal of the research was to propose and test development practices for developing audio control protocols with the XMOS platform. The target for the AES-64 stack and control application was an XMOS Ethernet AVB endpoint based around the XS1 microcontroller. This meant that:

The AES-64 stack and control application would clearly need to integrate and communicate with the Ethernet AVB endpoint software Interprocess communication between the AES-64 stack, control application and other components of the endpoint software would use the XS1 message-passing system

The XC programming language [14] provides accessible, C-like control over the native features of the XS1 architecture including task synchronisation and communication, inputoutput operations and event selection. The XS1 may also execute C code, and XC functions may call functions written

in C (and vice versa)4 ; as a result, modules written in C may be integrated into a larger XC program if they present a suitable interface for interprocess communication and any other I/O. However, XC also restricts usage of some common language features, most notably restricting the use of pointers [14, p. 14]. This presents difculties for tasks like parsing messages, and it was clear that some parts of the stack would be implemented in C. It was proposed that the AES-64 protocol stack could be developed in C and adapted, once a baseline of functionality was in place, into a set of concurrent processes (per the implementation model shown in Fig. 1) communicating via lightweight signalling and data exchange protocols implemented in XC. These protocols would also provide the required integration with the existing endpoint software, most notably actuating AES-64 parameter value functions. Considering the stated AES-64 requirement of uninterruptible actions, the concurrent processes approach would also enable an investigation of parallel request processing for the AES-64 stack (i.e., adapting the model shown in Fig. 1 to use multiple Message Processing threads.). A. Prototyping The original prototype of the AES-64 stack was developed and tested as a client-server socket application. This enabled rapid development of data structures and serialisation routines to implement the numerous message header types and command-specic value elds. Once the performance of these routines could be validated against the specication and requirements analysis, this prototype was deployed onto the XMOS Ethernet AVB endpoint to integrate it with the XMOS IP stack component, which does not provide a sockets programming interface [15]. This process produced two notable ndings. The AES-64 sockets prototype had originally implemented the device node level hierarchy as a linked list of linked lists. A recursive function was used to match supplied full address blocks. Use of recursion in C without clear bounds presents difculties for the XMOS toolchain, which performs static analysis of stack allocation as part of constraint checking during the build process5 . The toolchain does provide a workaround for this, but a decision was taken to re-implement the level hierarchy as a table structure. The second nding is more signicant. Since a single XC thread executes on a single core of an XS1 processor, its total memory requirements are bounded by the 64KB RAM onboard the core. Testing and analysis showed that 64KB was inadequate to fully integrate the single-threaded AES64 protocol stack prototype with the Ethernet AVB endpoint control application.
4 Although some macros are required (and provided) to reconcile the differences in XC and C reference parameter syntax. 5 Each core of an XS1 processor has 64KB of on-chip RAM. This RAM must hold the cores bootloader, the program binary, the stack and the heap, although developers could theoretically implement a hardware interface to off-chip RAM if required.

B. Multithreaded implementation The multithreaded implementation of the AES-64 stack closely resembles the implementation model shown in Fig. 1. The functionality of the AES-64 protocol stack has been distributed between the Ethernet AVB endpoints control thread, a device representation thread, and one or more message processing threads6 . Listing 1 shows the commands dened for the Ethernet AVB endpoints control application to signal the rest of the AES-64 protocol stack.
Listing 1. AES-64 stack control protocol enum A64CtrlCommand { A64_CTRL_INVALID_COMMAND=0xC0, /* These commands are dispatched to * a message processing thread */ A64_CTRL_PROCESS_MESSAGE, A64_CTRL_PROCESS_RESPONSE, A64_CTRL_NOTIFY_TX_COMPLETED };

In this task allocation, the control application is responsible for: receiving, queuing, submitting (to a message processing thread) inbound AES-64 messages transmitting outbound AES-64 messages actuating parameter value functions A message processing thread (MP thread) is responsible for: parsing and processing requests received by the device, and querying the device representation thread submitting outbound AES-64 messages to the control thread for transmission signalling the control thread to actuate a parameter value function The device representation thread holds the device node(s) that represent the device, and also processes read/write and related requests from the MP thread(s). This thread must be supplied with a function, a64_device_configuration_init(), that congures at least one device node. Communication between the threads has been implemented through a protocol that sends an asynchronous command event, and in most cases waits for the other end to acknowledge before sending serialised data: for example, an A64_CTRL_PROCESS_MESSAGE event (Listing 1) is followed by a message length value and the bytes of the message to be processed. Each thread waits for an identied set of events to occur. The device representation thread (Listing 2) enables each MP thread (notifying that it is fully congured) and thereafter waits to handle query events from any of them (e.g., A64_MP_RESOLVE_FULL_ADDRESS_BLOCK or A64_READ_PARAM_VALUE_FUNCTION).
6 The number of message processing threads can be set in a conguration le; after this, the developer must manually allocate the threads to cores in the softwares top-level parallel block, but otherwise the stack autocongures to run with any nonzero number of message processing threads that can run within the resources of the XS1 processor.

Listing 2. The device representation thread selects events from message processing threads select mp_request(chanend c_mp, unsigned char token, enum A64MPCommand mp_cmd);
2

Listing 3. The control thread selects events from message processing threads select a64_fs_mp_handler(chanend c_msg_proc, chanend tcp_svr, unsigned char token, enum A64MPCommand mp_cmd, UInt32 numbytes, UInt32 mp_uid);
2

10

12

14

16

18

void a64_dnm(chanend c_ctrl_app, chanend c_msg_proc[], int num_mp_threads) { /* Omitted: device representation configuration */ /* Send an enable to each of the mp threads, giving a UID */ for (int mp_uid = 0; mp_uid < num_mp_threads; mp_uid++) { a64_msg_proc_api_enable_processing (c_msg_proc[mp_uid], mp_uid); } /* Now wait forever on requests from the mp threads */ while (1) { enum A64MPCommand mp_cmd = A64_MP_INVALID_COMMAND; select { case (int mp_uid = 0; mp_uid < num_mp_threads; mp_uid++) mp_request(c_msg_proc[mp_uid], token, mp_cmd); } } }

10

while (1) { select { /* ... */ /* Handler for message processor events */ case (int mp_uid = 0; mp_uid < num_msg_proc_threads; mp_uid++) a64_fs_mp_handler(c_msg_proc[mp_uid], tcp_svr, token, mp_cmd, nbytes, mp_uid); break; } }

On line 15, the device representation thread uses an XC replicator and the parameterised select function mp_request() to wait fairly on events from any of the MP threads7 . When an event does arrive, mp_request() identies it and calls a corresponding request handler (e.g., dnm_handle_read_param_value_function()) implemented in C, which itself calls an XC function (e.g., dnm_get_param_id_data()) to retrieve the serialised data that the MP thread is waiting patiently to send. The is then used to call one or more C functions adapted from the original single-threaded AES-64 stack (e.g., a64_retrieve_param_value_function()). Further XC functions may be called if required (e.g., to issue a response). The Ethernet AVB endpoints control thread also uses a replicator and parameterised select function (Listing 3) to wait on events from the array of message processing threads (Fig. 2). C. Example - Ethernet AVB connection management Audio is transmitted on an Ethernet AVB network from a Talker to one or more Listeners as a stream. The Talker advertises its stream on the network using a unique stream ID. In order to receive a stream, the Listener must be instructed to respond to a specic Talkers stream advertisement, which can be identied by its stream ID.
7 Fairly means that every event sent will be received and acted upon; no event will be ignored. For a detailed description of this XC mechanism, see [14, pp. 25-27]

Fig. 2. The control thread waits on four types of events from an array of message processing threads: 1) processor enabled notications, 2) transmit message requests, 3) status notications, 4) value function requests. Events are selected fairly by the control thread regardless of their source.

To connect a stream between a Talker and Listener, an AES-64 controller must retrieve the Talkers stream ID and communicate it to the Listener. As outlined by Foulkes [6, pp. 316-7], this involves two parameters on the Listener: a Boolean LISTEN parameter and a 64-bit integer STREAM ID parameter. To prompt the device to respond to the Talkers Talker Advertise declaration, the controller must submit set value requests targeting the STREAM ID parameter (supplying the Talkers stream ID) and LISTEN parameter (supplying the value true)8 . The control task receives each request and submits the rst to a message processing thread (MP thread), marking the thread as unavailable. If no MP thread is available to process the second request, it is queued until one becomes available. The MP thread parses the request. It submits an A64_MP_READ_PARAM_VALUE_FUNCTION event to the device representation thread, using the supplied parameter ID, to retrieve the parameters value function attribute. It then
8 We will assume that the target of each request is addressed with a parameter ID rather than a full address blocks.

submits a A64_MP_SET_PARAM_VALUE event to the control application, providing the value function identiers and the new value. This results in a call to the XMOS Ethernet AVB API: for the STREAM ID parameter, the A64_MP_SET_PARAM_VALUE event will result in a call to the set_avb_sink_id() function. for the LISTEN parameter, the A64_MP_SET_PARAM_VALUE event will result in a call to the Ethernet AVB APIs set_avb_sink_state() function, resetting the Listener state and prompting it to attach to any Talker advertising the stream ID currently set. Once the MP thread has submitted the A64_MP_SET_PARAM_VALUE event, it submits an A64_MP_NOTIFY_PROCESSING_COMPLETE event to the control thread, which marks the MP threads state as available. If the MP thread encounters a problem processing the request message (e.g., because the parameter ID supplied is invalid), it abandons processing and returns a A64_MP_NOTIFY_PROCESSING_FAILED event, which is handled in the same way. D. Command-line utilities Command-line utilities were developed to test and control the AES-64-enabled Ethernet AVB devices. These utilities implement network discovery, stream and internal connection management, and monitoring of device status via AES-64 messaging. The utilities also demonstrate proof-of-concept implementations of device enumeration and the AES-64 join mechanism. Finally, a network analyser was used with these utilities to measure the latency of the AES-64 implementation. V. R ESULTS The research has provided a scalable implementation of AES-64 control and connection management over XMOS Ethernet AVB endpoints. The implementation is not restricted to controlling Ethernet AVB functions9 . The latency of the implementation has been measured as the time between a request transmission and its corresponding response. Table II presents mean processing times as derived from 50 measurements of common control tasks. These fall within the common cited latency requirement of 5ms [16, p. 65]. The research has demonstrated a structured development process that produces a coherent design and implementation of a complex audio control protocol on the XMOS XS1 platform. The research has demonstrated that the XMOS XS1 architecture and the XC language provide a compelling platform for the development of audio control protocols, where the opportunity to exploit parallel processing of requests is highly attractive. The XMOS XS1 implementation of messagepassing concurrency has facilitated secure and elegant structuring of an implementation addressing complex requirements.
control over audio hardware has been demonstrated; due to space restrictions, it is not presented in this paper.
9 e.g.,

TABLE II AES-64 REQUEST PROCESSING TIMES IN MICROSECONDS Request Network discovery: Get IP Address param value Stream connection setup: Get Talker Stream ID param value Set Listener Stream ID param value Enable Listener LISTEN param Stream connection teardown: Disable Listener LISTEN param Stream channel assignment: Set Listener CHANNEL MAP value Mean (s) 423 363 295 316 353 1108 Median (s) 415 382 299 327 350 430

VI. C ONTRIBUTION The research has provided an implementation of AES-64 that directly controls an Ethernet AVB endpoint where none previously existed. R EFERENCES
[1] AES Standards Committee, AES standards project report: Use cases for networks in professional audio, Audio Engineering Society, Tech. Rep., 2008. [2] IEEE 1722, IEEE 1722 standard for layer 2 transport protocol for time sensitive applications in bridged local area networks, 2012. [3] IEEE 802.1Qat, IEEE Std 802.1Qat standard for local and metropolitan area networks: Virtual bridged local area networks amendment 14: Stream reservation protocol, September 2010. [4] IEEE 802.1Qav, IEEE Std 802.1Qav standard for local and metropolitan area networks: Virtual bridged local area networks amendment 12: Forwarding and queueing enhancements for time-sensitive streams, January 2010. [5] AES, AES-64 standard for audio applications of networks - command, control and connection management for integrated media, 2012. [6] P. Foulkes, An investigation into the control of audio streaming across networks having diverse quality of service mechanisms, Ph.D. dissertation, Rhodes University, September 2011. [7] P. Foulkes et al., Network neutral control over quality of service networks, J. Audio Eng. Soc, vol. 59, no. 11, pp. 835844, 2011. [Online]. Available: http://www.aes.org/e-lib/browse.cfm?elib=16151 [8] XMOS, XMOS AVB design guide, 2011. [Online]. Available: http://www.xmos.com/published/avb-reference-design-guide-0 [9] , AVB LCB reference design product brief, 2011c. [Online]. Available: http://www.xmos.com/published/avbl2pb?version=latest [10] J. Dibley and R. J. Foss, An investigation into the AES X170 project for control of Ethernet AVB networks, in SATNAC 2012 Proceedings, S. Scriba, Ed., no. 978-0-620-53713-1. Telkom SA, 2012, pp. 141146. [11] N. Chigwamba, et al, Parameter relationships in high-speed audio networks, Journal of the Audio Engineering Society, vol. 60, no. 1/2, March 2012. [12] P. Ward and S. Mellor, Structured development for realtime systems, vols 1 3. Yourdon Press, 1985. [13] H. Gomaa, A software design method for real-time systems, Communications of the ACM, vol. 27, no. 9, pp. 938949, 1984. [14] XMOS, XC programming guide, November 2011a. [15] , XMOS TCP/IP stack design guide, March 2012. [Online]. Available: http://www.xmos.com/published/xmos-tcpip-stackdesign-guide [16] K. Gross, Audio networking: Applications and requirements, Journal of the Audio Engineering Society, vol. 54, no. 1/2, pp. 6266, January/February 2006.

James Dibley is an MSc candidate and a member of the Audio Research Group in the Department of Computer Science at Rhodes University.