Operating Systems Latency Measurement and Analysisfor Sound Synthesis and Processing Applications

Adrian FreedAmar Chaudhary

Brian DavilaCNMAT, UC Berkeley

adrian,amar,davila@cnmat.berkeley.edu, http://www.cnmat.berkeley.edu/People

Abstract

There is increasing interest in using personal and workstation computer platforms for reactive soundsynthesis and processing applications. Much experimentation and tuning is required with each operatingsystem and hardware platform to achieve acceptable real-time performance for such applications. Tools tomeasure I/O latencies are critical for this tuning process. This paper introduces an affordable hardware-oriented measuring system.

1 IntroductionDesktop and workstation computers are now veryattractive for reactive sound synthesis and processingapplications. Unfortunately few operating systemswere designed to deliver real-time performance andvendors generally don't guarantee or even specify thetemporal performance of operating systems.Considerable experimentation is required with eachoperating system to achieve acceptable musicalresults.

Measurement of I/O latency is fundamental toachieving reliable real-time performance for musicalapplications and is the primary focus of this paper.The first challenge is to synchronously log stimulusevents communicated with MIDI, ethernet, USB,IEEE-1394, audio input, etc., and subsequent changesin processed or synthesized audio sound streams.

"In vivo" measurement of latencies in mostcomputing and networking systems is challenging.Even in the rare systems where time stamping isavailable, most logging techniques interfere with theperformance of the system being evaluated. Also,many of the latencies to be characterized are hardwarebuffers inaccessible to software, e.g. FIR filter delayin audio codec reconstruction filters.

In this paper we describe an affordable hardware-basedlatency evaluation strategy applicable to anyoperating system or computer.

2 Event Logging

2.1 Audio TranscodingModern instrumentation tools such as logic analyzersand digital storage oscilloscopes can perform eventlogging but are expensive and challenging toconfigure.

The simpler approach used here is to convert eventsfrom a wide range of sources into audio frequencysignals. These signals and synthesized sound outputsare synchronously analyzed or recorded using standardmultichannel audio recording tools, such as an ADATrecorder connected to an SGI O2 computer.

The multi-channel audio stream serves to bondtogether the event streams maintaining their temporalrelationships despite latencies in the analyzingsystem.

This technique has been used [1] in stereo form toanalyze timing relationship between key displacementand sound from a pipe organ.

The logging system requires a circuit to interfacecleanly and non-invasively with the source of eventinformation and a way to modulate events in theaudio frequency range.

1

2

3

45

220

1N914

8

3

2

All resistors1/4 Watt 5%

1

TLC 555

4.7K

3

1

4

7

6,2

1K

8

V+

100

1uF

3,16,9,10,11

100K

100K

220pF

13

15

14

74HCT123

V+

BNCconnectorto scope probe

100K

1M

100K

10nF

100K

100K

100nF

1

2

8

2

8-pin10BaseTconnector

6N139

10K

1K

+

MIDIIn

1.5V

1.5V+

AudioIsolationTransformer

Out

6

5

Circuit Diagram of the Event Transducer.

2.2 InterfacingFor MIDI events the logging circuit uses opticalisolation as specified in the MIDI standard. This isinherently non-invasive since the logging circuit maybe connected to a MIDI thru output.

A standard 8-pin T-connector is used For 10BaseTEthernet to tap into the transmission or receptiondifferential pair. Input resistors and the CMOSinputs of a 74HCT123 satisfies the requirement for ahigh impedance, non-invasive connection.

2.3 Down Sampling CircuitryPulse streams from Ethernet and MIDI are clocked athigher rates than available audio bandwidth, so someinformation will be lost down-sampling. A74HCT123 monostable multivibrator is used tostretch out data transitions by a fixed time intervalthat is long enough to gate an audio oscillatorimplemented with a CMOS 555 timer. Details ofeach bit transition are lost in this scheme, but theevent beginnings are accurately captured.

The time constant of the retriggerable monostable isthe temporal uncertainty of the end of an event. The

time constant is set to provide adequate accuracy whenlogging at audio rates.

The oscillator output drives an audio frequencyisolation transformer. This isolates the circuit fromthe audio system, eliminating ground loops. The useof battery power supply allows the input to float,minimizing common mode problems.

The choice of 3V supply is important. It allows thefront-end to successfully capture transitions from awide variety of inputs including RS422, TTL, RS232and MIDI current loop. The high resistance valueschosen in the front end are important: they providecurrent limitation for the protection diodes built intothe 74HCT123’s inputs which are used here forclamping.

Note that the circuit exploits the two trigger inputs ofthe multivibrator avoiding a switch between thecurrent loop and other event sources. The desiredsource is simply plugged in. Both these inputs havespecial internal circuits with hysteresis to minimizefalse triggering and improve noise immunity.

3 ResultsThe circuit described here is one of a set of toolsbeing developed as part of a broad initiative, theResponsive Systems Validation Project (RSVP) [3].These tools have been used to measure soundsynthesis software performance on SGI, Macintoshand PC machines with MIDI, Ethernet and gesturalinput devices such as digitizing tablets [2].

The original thought behind the latency measurementtools was to use them to tune sound synthesissoftware on each platform towards the latency goal of10 ± 1mS. Although such a goal is within sight onthese systems, the measurement tools revealedsignificant bugs and design flaws in the underlyingoperating systems and computers with respect to real-time performance. Since work to address these flawsis being vigorously pursued by some of the vendors,it would be unfair to publish particular numbers atthis stage - numbers that would be meaningless bythe time you read this. Progress may be gauged bymonitoring the aforementioned RSVP web pages.

It is encouraging that the performance difficultiesidentified by latency measurement tools were notfrom inadequate real-time features in the operatingsystems, but design and implementation decisionsthat defeat real-time requirements. A pervasive

difficulty stems from poor implementations of I/Odrivers. Programmers still cut corners by holding offinterrupts for long periods. This is especiallytroublesome on systems assembled from manyvendors, i.e. Intel PC’s, since there is no industrywide real-time validation suite in use to catch thissloppiness. Widespread use of affordable tools suchas the one described here will eventually result inaffordable reactive computing.

4 Future WorkMore sophisticated front-end hardware is required tomonitor USB and Firewire.

A small run of a multichannel version of the circuitoutlined here is planned.

5 AcknowledgmentsWe gratefully acknowledge the financial support ofEmu Systems, Gibson, and Silicon Graphics Inc.Doug Cook and Chris Pirazzi clarified manyperformance and timing issues on SGI machines.

References[1] Kostek, B., A. Czyzewski, 1993, “Investigation

of Articulation features in Organ Pipe Sound,”Archives of Acoustics, vol.18, (no.3):417-34.

[2] Wright, M., D. Wessel, A. Freed, 1997. “NewMusical Control Structures from StandardGestural Controllers,” proc. ICMC,Thessaloniki, Greece.

[3] http://www.cnmat.berkeley.edu/RSVP