TS 26.119 assumes a common XR Baseline Client architecture. An essential characteristic is that a functional split is envisioned between a Presentation Engine comprising a set of composite renderers that are controlled by a Scene Manager and an XR Runtime performing a set of functions that interface with a platform to perform commonly required operations, e.g. post-rendering, prior to final output. The relevant interface between Presentation engine and end device may be a 5G physical interface between, e.g., between a smartphone or 5G EDGE and a lightweight device (AR glasses) like those considered in 5G EDGe-Dependent AR (EDGAR) and 5G Wireless Tethered AR UEs as described in TR 26.998 or those considered in TR 26.806. The functional split assumed in split renderer architectures is a result of stringent implementation and operational requirements applicable for rendering of XR media on XR devices. For head-tracked immersive audio, the need to rely on a split renderer architecture, may depend on various factors among which the round-trip latency between the renderer in the presentation engine and the lightweight device is a decisive parameter. There are scenarios where this latency may be substantial which may prefer a split rendering approach with pose correction in the end device for binaural audio in a similar way as for video unless decoding and head-tracked binaural audio rendering on the lightweight device does not exceed its strict complexity constraints. In other scenarios, that latency may be sufficiently low, in which case the head-tracked binaural rendering can exclusively be done in the presentation engine. It is notable that the transmission over the interface may generally be bit rate constrained and dependent on the specific physical interface. Binaural audio rendering comprises of signal processing functionalities that may include:

• Binauralization of audio input based on head rotation (3DoF),
• Binauralization of audio input based on listener position and head rotation (6DoF),
• Room acoustics synthesis.

Audio input to be rendered may be a combination of diegetic immersive (3D audio) and non-diegetic sounds. The diegetic immersive sounds need to be binauralized using the up-to-date head rotation data. The head rotation data is typically originating from the head-tracker available from the lightweight end device. The room acoustic synthesis can be performed using room impulse response data or parametric representation thereof, typically supplied to the Presentation Engine. Depending on constraints and design preferences of the lightweight device (AR glasses, earbuds, etc.) and the properties of the interface between Presentation Engine and end device, solutions are needed that among more are compliant with TR 26.928 and TR 26.998. The solutions shall address given interface characteristics and not impose any new requirements for them. Another aspect is the currently ongoing standardization of the EVS Codec Extension for Immersive Voice and Audio Services (IVAS) codec. While low complex rendering for lightweight devices is not a specific design objective, the IVAS codec work item should ideally provide solutions that would enable using IVAS services over head-tracked lightweight clients meeting relevant requirements. Bearing in mind the evolution of the AR/XR technologies, it would be desirable to design low complex solutions for head-tracked binaural audio rendering on lightweight devices that under certain limitations are agnostic in a sense that the pre-renderer component in the presentation engine could be connected with any immersive binaural audio framework through suitable APIs. The solutions to be specified are intended to add to the number of rendering options to enable immersive audio services on a broad range of devices, including light-weight AR glasses or earbuds. The pre-rendering part of the solutions is expected to become non-mandatory but shall fulfill the relevant requirements set out under this work item. It should interface through a fully specified intermediate bitstream with a fully specified split rendering decoder. For end device implementations claiming support of a specific solution, a fully compliant implementation of at least the split rendering decoder shall be required. Other end device implementations not claiming support of a specific solution remain at the discretion of the implementor.

The overall objective of this work item is to develop solutions for immersive binaural audio on head-tracked devices that are compatible with the envisaged split architectures (TS 26.119, TR 26.998). The solutions should consider low-complex and lightweight devices and demonstrate operational benefits over solutions with full decoding and rendering in the end device. The following objectives should be achieved with the work item:

• Provide format specification for intermediate representation(s).
  • Provide functional requirements for (pre-)renderer operations to be carried out by Presentation Engine.
  • Define suitable APIs.
• Provide encoder, bitstream and decoder specification for intermediate representations including audio with and without post-rendering control metadata.
• Provide a specification for decoded intermediate representations to provide binaural audio output with and without head-tracker input and post-rendering control metadata.
• Consider potential solutions offered by the IVAS work item, and specify the necessary interfaces.

The work item shall in a first phase identify and agree relevant requirements to be documented in a TR. This shall cover:

• Design constraints related to complexity and memory as well as constraints related to relevant interfaces between presentation engine and end device such as bit rate, latency, down- and upstream traffic characteristics.
• Design constraints related to functional capability requirements such as rendering of non-diegetic sounds, 3DoF rendering of diegetic immersive sounds, 6DoF rendering of diegetic immersive sounds, including simultaneous rendering of different sound categories, and room acoustics synthesis.
• Performance requirements.

The solution(s) are characterized for the range of relevant interface characteristics between presentation engine and lightweight device. The case where the immersive audio is decoded and rendered within the end device should be considered as a reference. The requirements will be documented in a first technical report. The developments under this work item shall lead to a new specification defining among others textual descriptions of the involved renderers and codec (incl. frame loss concealment) of the intermediate representation(s). The performance of the developed solutions in relation to the requirements will be documented in a second technical report. Solutions meeting the ISAR split rendering requirement may be added to the set of IVAS codec specifications (by means of CRs) if they are found suitable for IVAS. The developed solutions should also be referenced in TS 26.119. Specific split rendering solutions for IVAS should comprise a non-mandatory default split rendering encoder for the specified internal and stand-alone IVAS renderers. In addition, for a given specific solution there should be specified interfaces offering the possibility either to connect a given (proprietary) renderer for IVAS to the intermediate representation encoder or to use proprietary pre-renderers/intermediate encoders to produce compliant intermediate bitstreams. Such proprietary solutions shall be compliant with the relevant requirements documented in the first technical report. ISAR end device implementations for IVAS claiming support of a specific solution shall be required to have at least a fully compliant split rendering decoder. Other decoder/post-renderer implementations not claiming support of a specific ISAR solution for IVAS remain at the discretion of the implementor.