ADM-OSC

Living Standard,

This version:
https://immersive-audio-live.github.io/ADM-OSC/
Previous Versions:
Test Suite:
https://github.com/immersive-audio-live/ADM-OSC/tree/main/tests
Issue Tracking:
GitHub
Inline In Spec
Editors:
(d&b audiotechnik)
(L-Acoustics)

Abstract

An industry initiative for standardization of Object-Based Audio positioning data in live production ecosystems by implementing the Audio Definition Model over Open Sound Control. See: [ADM-OSC-1]

1. Introduction

ADM-OSC has been designed to solve real problems for live and broadcast sound producers. Since 2019, a growing workgroup of industry stakeholders from live music and broadcast domains has gathered to exchange needs and experiences from real-life production cases. These companies have already expressed interest or have implemented ADM-OSC:

Version 1.0 of the ADM-OSC specification was announced at the AES Show in 2024 [ADM-OSC-1].

1.1. Why ADM?

Immersive audio is gaining ground in different industries, from music streaming to gaming, from live sound to broadcast. ADM is becoming a popular standard metadata model in some of these industries, with serialADM used in broadcast or ADM bwf or xml files used in the studio.

1.2. Why OSC?

1.3. Motivation & goals

1.4. Project Originators

L-Acoustics, FLUX::SE, Radio-France

1.5. Project Contributors

Adamson, BBC, d&b audiotechnik, DiGiCo, Dolby, Lawo, Magix, Merging Technologies, Meyer Sound Laboratories, Steinberg

2. Current spec (v1.0)

2.1. Object position messages

Note: These messages take the form of /adm/obj/n..., where n signifies object number

address type units min max default description example
/adm/obj/n/azim f degrees -180.0 180.0 azimuth “theta - θ” of sound location
§ 4.4.1 Polar
/adm/obj/4/azim -22.5
/adm/obj/n/elev f degrees -90.0 90.0 elevation “phi - ɸ” of sound location
§ 4.4.1 Polar
/adm/obj/4/elev 12.7
/adm/obj/n/dist f normalized 0.0 1.0 1.0 distance “r” from origin
§ 4.4.1 Polar
/adm/obj/4/dist 0.9
/adm/obj/n/aed f f f azimuth elevation distance synchronicity and reduced network traffic /adm/obj/4/aed -22.5 12.7 0.9
/adm/obj/n/x f normalized -1.0 1.0 0.0 left/right
§ 4.4.2 Cartesian
/adm/obj/4/x -0.9
/adm/obj/n/y f normalized -1.0 1.0 0.0 front/back
§ 4.4.2 Cartesian
/adm/obj/4/y 0.15
/adm/obj/n/z f normalized -1.0 1.0 0.0 top/bottom
§ 4.4.2 Cartesian
/adm/obj/4/z 0.7
/adm/obj/n/xy f f see above synchronicity and reduced network traffic /adm/obj/4/xy 0.62 -0.33
/adm/obj/n/xyz f f f see above synchronicity and reduced network traffic /adm/obj/4/xyz -0.9 0.15 0.7
/adm/obj/n/w f normalized 0.0 1.0 0.0 horizontal extent in normalized units /adm/obj/3/w 0.2
/adm/obj/n/gain f linear 0. 1.0 Apply a gain to the audio in the object. /adm/obj/3/gain 0.707
/adm/obj/n/dref f normalized 0.0 1.0 1.0 Distance where dimensionless rendering is replaced with with physics-based rendering.
§ 4.4.4 Distance
/adm/obj/1/dref 0.2
/adm/obj/n/dmax f meters 0. Distance signified by a normalized dref value of 1
§ 4.4.4 Distance
/adm/obj/1/dmax 21.3
/adm/obj/n/mute i integer 0 1 0 1 means “true”, so muted /adm/obj/2/mute 0
/adm/obj/n/name s string 0 128 char object nice name /adm/obj/1/name kickdrum

Note: Type tags are defined as OSC 1.0 specification: i=int32, f=float32, s=OSC-string

2.2. Environment messages

These could be expanded to include program changes and other global data. They are not specific to any individual object.

address type units min max default description example
/adm/env/change s string 0 128 char 128 char program changes /adm/env/change day

2.3. Listener messages

These messages could be used by a binaural renderer [EBU-Tech-3396] for head tracking data and listener position in a 6DOF setting.

address type units min max default description example
/adm/lis/ypr f f f degrees -180.0 180.0 0.0 orientation: yaw, pitch, roll /adm/lis/ypr -45.0 30.0 5.0
/adm/lis/xyz f f f normalized -1.0 11.0 0.0 listener position /adm/lis/xyz 0.0 0.5 -0.2

2.4. Queries and bi-directional communication

The OSC protocol is unidirectional, so the commands should be considered as SET from a sender to a receiver. A particular device might also be interested to GET the state of a particular parameter in another device. To do so, it should send a command without any arguments. The receiver should answer back to this IP with the data.

sending /adm/obj/4/xyz to a device should trigger a reply like /adm/obj/4/xyz -0.9 0.15 0.0

3. Implementation Matrix

Issue #24 on GitHub: “Implementation matrix”

Table of implementations.

What do they support?
What they would like to support?

✓ = transmit and receive
tx = transmit only
rx = receive only
Zactrack (Merging Technologies)
Ovation
(Merging Technologies)
Pyramix
(Figure 53)
QLab
(FLUX::)
SPAT Revolution
(L-Acoustics)
L-ISA Controller
(Lawo)
mc2 consoles
(d&b Soundscape)
En-Bridge
(Meyer Sound Laboratories)
SpaceMap Go
(Steinberg)
Nuendo
(Adamson)
FletcherMachine
(New Audio Technology)
Spatial Audio Designer
(Modulo Pi)
Modulo Kinetic
(TiMax Spatial)
Timax panLab
/adm/obj/n/azim tx rx rx rx
/adm/obj/n/elev tx rx rx rx
/adm/obj/n/dist tx rx rx rx
/adm/obj/n/aed tx rx rx rx
/adm/obj/n/x tx rx rx
/adm/obj/n/y tx rx rx
/adm/obj/n/z tx rx rx
/adm/obj/n/xy rx rx
/adm/obj/n/xyz tx tx tx rx rx
/adm/obj/n/w tx rx
/adm/obj/n/dref
/adm/obj/n/dmax ✓ *
/adm/obj/n/gain tx rx rx
/adm/obj/n/mute rx
/adm/obj/n/name tx rx
/adm/env/change
/adm/lis/xyz tx rx rx
/adm/lis/ypr rx rx

Note: * FletcherMachine and SPAT Revolution supports dmax as a global message only: /adm/obj/*/dmax

4. Basic ADM-OSC principals

4.1. Roles

4.1.1. Sender (client)

4.1.2. Receiver (server)

4.2. Ports

ADM-OSC typically uses UDP protocol. It is recommended to use port 4001 [ADMix] for one-way communication (so, default for senders and receivers) and 4002 for return messages (if used).

Those ports should be user editable if needed.

4.3. Message rate

Position data is typically sent at a high data rate, although care must be taken not to overload the capibilities of the receiver. S-ADM is usually half of the video frame rate, or approximatly one message every 20 ms, or 50 Hz. Similarly, the Dolby Atmos ADM Profile [Atmos-Profile] recommends that the sampling period be "less than 20 ms," although sampling is optional if the parameter does not change.

Interpolation messages have not been implemented in ADM-OSC 1.0.

4.4. Coordinates

4.4.1. Polar

4.4.2. Cartesian

(-1, 1) --------- (1, 1)  
   |                |  
   |                |  
   |                |  
   |                |  
(-1, -1) ---------(1, -1)  

4.4.3. Conversions

To convert the coordinate system, Euler trigonometry can be used to represent the polar sphere in cartesian coordinates. The equations are provided in ITU-R BS.2127 section 6.8 [EBU-BS-2127]

x = - d sin ( π 2 - e 2 π 360 ) sin ( a 2 π 360 )
y = d sin ( π 2 - e 2 π 360 ) cos ( a 2 π 360 )
z = d cos ( π 2 - e 2 π 360 )
Cartesian to polar conversion
a = 360 2 π atan2 ( x , y )
e = 360 2 π asin ( z d )
d = x 2 + y 2 + z 2
polar to Cartesian converision

To help conversions seamlessly, here are code examples on GitHub in SWIFT [convert-swift], in CPP [convert-cpp] or JavaScript [convert-js].

For full ADM compatibility, there is another recommended conversion approach in section 10.1 of: [EBU-BS-2127]. C++ code for that conversion can be found at [EBU-convert-cpp].

Issue #25 on GitHub: “Polar to Cartesian and vice-versa conversion”

We probably cannot settle on an aligned approach on how to convert Polar to Cartesian systems and vice-versa. However can we at least propose something everybody can stand behind so that when someone uses ADM-OSC, the same results are achieved?

4.4.4. Distance

The 3D paradigm chosen by the ADM standard is a normalised (dimensionless) reference volume, defined in Cartesian or spherical coordinates.

-1.0 x 1.0
-1.0 y 1.0
-1.0 z 1.0
dimensionless ADM cube
0.0 d 1.0
d = distance or radius
dimensionless ADM sphere

This paradigm is used by studio/broadcast mixing tools such as Dolby Atmos or MPEG-H.

On the other hand, some audio renderers represent a physics-based world, and the notion of source distance relates to a physical unit, such as meters. Aside from direct sound gain, the source physics-based distance dm relates to advanced audio object parameters such as propagation delay, air at- tenuation, and energy levels of early/cluster reflections and late reverberation, or sound field behaviors (plane vs spherical waves).

These audio renderers include L-Acoustics L-ISA, Flux:Spat, d&B Soundscape, but also, more generally in the AR/VR domain, game audio engines such as Unreal, Unity, Wwise, or XR audio engines such as Magic Leap Soundfield Audio. A common challenge for all these renderers based on physical distance is that if the gain follows physical attenuation laws (such as “-6dB per doubling of distance”), there are some singularities when dm gets close to 0. Hence, most of these renderers include a “volume of reference” or “unit volume” where the rendering (and in particular the gain) do not follow physically-informed laws anymore. This is true for Unreal and Spat, for example.

An object position in a physics-based world can be described as:

x min x x max (meters)
y min y xMax (meters)
z min z xMax (meters)
physics-based Cartesian
0.0 d mimn d max (meters)
physics-based spherical

In ADM-OSC, /dmax corresponds to the absoluteDistance parameter in an ADM audioPackFormat element.

/dref is a new parameter can be defined as the radius in meters of a volume of reference, which would serve the two purposes. It coincides with the dimensionless volume used in the ADM standard and it is used by physically informed renderers as the “volume of reference” where the laws of physics do not apply, and the gain(dB) is constant regardless of distance.

By definition:

0 d ref d max 1

and the following cases arise:

d ref = 1 : the world is a dimensionless reference d max volume, matching the ADM standard
d ref = 0 : no reference volume within the physical d max world
Issue #12 on GitHub: “Distance”

Different rendering systems handle distance differently. ADM uses a "dimensionless" reference volume, the interior of a cube or sphere. There are also physics-based renderers (eg Game engines) that try to acoustically represent distance based on a simulation of distance in meters, for example.

The proposal is to define both reference distance (dRef) and a maximum distance (dMax) messages in ADM-OSC so to communicate the intended rendering approach. The default (and current behaviour of the ADM standard) would be dRef = dMax = 1m. If dRef < dMax, then distance based tranforms (such as gain changes) could be applied when an object's distance is > dRef. Inside of dRef, no transforms would be applied.

5. Development & Test tools

5.1. Chataigne module

(Mathieu Delquignies / d&b audiotechnik)

To retreive parameters or control ADM-OSC object-based audio software or hardware with OSC protocol.

5.2. Tester Desktop application

(Jose Gaudin / Meyer Sound Laboratories)

download from resources directory

5.3. Validator, Test and Stress Test Python Module

(Gael Martinet / FLUX::)

adm_osc module is available to install through pip:

pip install adm-osc

quick examples:

from adm_osc import OscClientServer

# create a basic client/server that implement basic ADM-OSC communication with stable parameters 
# + command monitoring and analyze
cs = OscClientServer(address='127.0.0.1', out_port=9000, in_port=9001)

# send some individual parameters  
cs.send_object_position_azimuth(object_number=1, v=-30.0)
cs.send_object_position_elevation(object_number=1, v=0.0)
cs.send_object_position_distance(object_number=1, v=2.0)

# or pack them
cs.send_object_polar_position(object_number=1, pos=[-30.0, 0.0, 2.0])

# in cartesian coordinates
cs.send_object_cartesian_position(object_number=1, pos=[-5.0, 8.0, 0.0])

# see documentation for full list of available functions

# when receiving an adm osc command its analyze will be printed on the command output window
#
# e.g.
#
# >> received valid adm message for obj :: 1 :: gain (0.7943282127380371)
# >> received valid adm message for obj :: 1 :: position aed (20.33701515197754, 0.0, 0.8807612657546997)
# >> received valid adm message for obj :: 1 :: position xyz (-0.2606865465641022, 0.8273822069168091, 0.0)
# >>
# >> ERROR: unrecognized ADM address : "/adm/obj/1/bril" ! unknown command "/bril/"
# >> ERROR: arguments are malformed for "/adm/obj/1/gain :: (1.4791083335876465,)":
# >>     argument 0 "1.4791083335876465" out of range ! it should be less or equal than "1.0"

from adm_osc import TestClient
# create a test client, assume default address (local: '127.0.0.1')
# test client can be used to test how receiver will handle all kind of parameters and parameters value range
sender = TestClient(out_port=9000)

# all stable parameters for a specific object
sender.set_object_stable_parameters_to_minimum(object_number=1)
sender.set_object_stable_parameters_to_maximum(object_number=1)
sender.set_object_stable_parameters_to_default(object_number=1)
sender.set_object_stable_parameters_to_random(object_number=1)

# all stable parameters for a range of objects
sender.set_objects_stable_parameters_minimum(objects_range=range(1, 64))
sender.set_objects_stable_parameters_maximum(objects_range=range(1, 64))
sender.set_objects_stable_parameters_default(objects_range=range(1, 64))
sender.set_objects_stable_parameters_random(objects_range=range(1, 64))

# all stable parameters for all objects
sender.set_all_objects_stable_parameters_minimum()
sender.set_all_objects_stable_parameters_maximum()
sender.set_all_objects_stable_parameters_default()
sender.set_all_objects_stable_parameters_random()

# see documentation for full list of available functions
from adm_osc import StressClient
# create a stress client, assume default address (local: '127.0.0.1')
# stress client will send huge amount of data to stress test the receivers
sender = StressClient(out_port=9000)
# do stress test in cartesian coordinates
sender.stress_cartesian_position(number_of_objects=64, duration_in_second=60.0, interval_in_milliseconds=10.0)
# do stress test in polar coordinates
sender.stress_polar_position(number_of_objects=64, duration_in_second=60.0, interval_in_milliseconds=10.0)

6. Discussion

6.1. Draft 0.5

A draft for version 0.5 was proposed but not adopted. This draft contains messages for greater compatibility with ADM in broadcast use cases. It brings up a potential problem of sending critical configuration messages over UDP. Whereas loosing a few high-rate

6.2. Relationship to ADM

ADM-OSC messages are designed to be translatable to (S-)ADM if needed. Messages that don’t translate into one (or more) ADM tag should not be in the /adm namespace.

Issue #33 on GitHub: “Quaternions?”

We've added some head tracker messages to ADM-OSC 1.0. Specifically, yaw-pitch-roll like:

/adm/lis/ypr f f f

Quaternions are more useful in many situations. Should we also have something like /quat?

7. Definitions

Audio Definition Model

The Audio Definition Model (ADM) was first published by the European Broadcast Union (EBU) in 2015 as a standard representation of audio metadata [1]. The goal of ADM is to support a broad range of use cases that include spatial and immersive audio, as well as interactive personalization and accessibility features [What-is-ADM]. ADM can be used to represent channel-based, scene-based, and object-based audio. It is defined by the EBU in ITU-R BS.2076 [EBU-BS-2076]

Object-Based Audio

Object-based representation encodes audio tracks along with positional and other data about how that audio should be reproduced, or rendered, during playback. Positional data is speaker-agnostic, allowing object-based mixes to be highly portable. A musician might audition a mix on headphones using a binaural renderer [EBU-Tech-3396] then perform at a venue with dozens of loudspeakers using a spatial renderer. That mix might then be rendered for streaming with a third renderer. [Tsingos-2017]

Open Sound Control

OpenSoundControl (OSC) is a data transport specification (an encoding) for realtime message communication among applications and hardware. OSC was developed by researchers Matt Wright and Adrian Freed during their time at the Center for New Music & Audio Technologies (CNMAT). OSC was originally designed as a highly accurate, low latency, lightweight, and flexible method of communication for use in realtime musical performance. They proposed OSC in 1997 as “a new protocol for communication among computers, sound synthesizers, and other multimedia devices that is optimized for modern networking technology”.

There are several open-source implementations that simplify developers’ adoption, The OSC 1.0 specification has been published in 2002.

Renderer

Six Degrees of Freedom

Forward/backward, up/down, left/right translation, combined orientation (yaw, pitch, and roll).

Index

Terms defined by this specification

References

Informative References

[ADM-OSC-1]
M. Delquignies, J. Gaudin, S. Thevenard, H. Larin, M. Zbyszynski, L. Zwicker. Implementation of ADM-OSC v1.0. 2024. URL: https://aes2.org/publications/elibrary-page/?id=22722
[ADMix]
Admix Player. 2019. URL: https://forum.ircam.fr/projects/detail/admix/
[Atmos-Profile]
Dolby Atmos ADM Profile specification. 2022. URL: https://professionalsupport.dolby.com/s/article/Dolby-Atmos-ADM-Profile-specification
[CONVERT-CPP]
CPP polar<>cartesian code example. URL: https://github.com/ChristianAhrens/RemoteProtocolBridgeCore/blob/master/Source/ProcessingEngine/ProtocolProcessor/OSCProtocolProcessor/ADMOSCProtocolProcessor.cpp
[CONVERT-JS]
Javascript polar<>cartesian code example. URL: https://github.com/madees/ADM-OSC-Chataigne-Module
[CONVERT-SWIFT]
SWIFT polar<>cartesian code examples. URL: https://github.com/Daniel-Higgott/ADMCoordinateConversion
[EBU-BS-2076]
Audio Definition Model. Spec. URL: https://www.itu.int/rec/R-REC-BS.2076
[EBU-BS-2127]
Audio Definition Model renderer for advanced sound systems. Spec. URL: https://www.itu.int/rec/R-REC-BS.2127
[EBU-convert-cpp]
EBU conversion between polar and cartesian coordinates. URL: https://github.com/ebu/ear-production-suite/tree/main/reaper-adm-extension/src/reaper_adm/coordinate_conversion
[EBU-Tech-3396]
BINAURAL EBU ADM RENDERER (BEAR) FOR OBJECT-BASED SOUND OVER HEADPHONES. Spec. URL: https://tech.ebu.ch/publications/tech3396
[OpenSoundControl.org]
OpenSoundControl website. URL: https://ccrma.stanford.edu/groups/osc/index.html
[Tsingos-2017]
N. Tsingos. Object-based audio. 2017. in Immersive Sound.
[What-is-ADM]
What is the ADM?. URL: https://adm.ebu.io/background/what_is_the_adm.html

Issues Index

Issue #24 on GitHub: “Implementation matrix”

Table of implementations.

What do they support?
What they would like to support?

Issue #25 on GitHub: “Polar to Cartesian and vice-versa conversion”

We probably cannot settle on an aligned approach on how to convert Polar to Cartesian systems and vice-versa. However can we at least propose something everybody can stand behind so that when someone uses ADM-OSC, the same results are achieved?

Issue #12 on GitHub: “Distance”

Different rendering systems handle distance differently. ADM uses a "dimensionless" reference volume, the interior of a cube or sphere. There are also physics-based renderers (eg Game engines) that try to acoustically represent distance based on a simulation of distance in meters, for example.

The proposal is to define both reference distance (dRef) and a maximum distance (dMax) messages in ADM-OSC so to communicate the intended rendering approach. The default (and current behaviour of the ADM standard) would be dRef = dMax = 1m. If dRef < dMax, then distance based tranforms (such as gain changes) could be applied when an object's distance is > dRef. Inside of dRef, no transforms would be applied.

Issue #33 on GitHub: “Quaternions?”

We've added some head tracker messages to ADM-OSC 1.0. Specifically, yaw-pitch-roll like:

/adm/lis/ypr f f f

Quaternions are more useful in many situations. Should we also have something like /quat?