Summary of S4-260122: License Proposal for DaCAS-2 Test Script

1. Introduction and Background

This contribution from Beijing Xiaomi Mobile Software Co., Ltd. addresses the licensing framework for the DaCAS-2 test script. The proposal builds upon the previous DaCAS-2 test script [S4-251827] and discussions from SA4#134 meeting. The document proposes standardized license text to be used by all contributors to the DaCAS-2 test script.

2. Main Technical Contributions

2.1 Proposed License Text

The document proposes a restrictive copyright and license framework with the following key characteristics:

• Copyright holder: Xiaomi Corporation (2026)
• Scope of permitted use: Exclusively limited to development and testing of DaCAS within 3GPP SA WG4
• Restrictions:
• All other uses strictly prohibited
• No patent license granted
• No license granted under any other intellectual property rights
• Liability disclaimer: Software provided "AS IS" with no warranties (express or implied) regarding accuracy, completeness, or sufficiency
• Limitation of liability: No liability for damages arising from software use

2.2 Multi-Contributor Framework

The document provides a template for updating the license when additional contributors join:

• Copyright expansion: Allows addition of multiple copyright holders (e.g., "Xiaomi Corporation and [XXX company]")
• Parallel updates: Contributor list to be updated in parallel with code changes
• Consistent terms: Same restrictive terms and liability disclaimers apply to all contributors collectively

3. Conclusion

The contribution seeks feedback from SA4 participants on the preliminary licensing terms outlined in Section 2.1. The proposed framework establishes a mechanism for maintaining an updated contributor list that evolves alongside code modifications as specified in Clause 2.2.

Evaluation Data for Device 3

1. Introduction

This contribution provides the recording database for Device 3, captured according to the evaluation recording scenarios defined in DaCAS-2 [1], specifically under Scenario 3 [2].

2. Recording Setup and Database Specifications

2.1 Physical Setup

The recordings were conducted in an anechoic chamber with the following configuration:

• Device placement: Center of anechoic chamber on a turntable
• Device orientation: Landscape orientation
• Source distance: d_UE = 1m
• Height: H = 1.3m (both UE and sound source)
• Speaker: GENELEC 8351

2.2 Recording Parameters

The database specifications are detailed in Table 1:

| Parameter | Specification | |-----------|---------------| | Target device | Device type 3 | | Recording scenario | Scenario 3 | | File naming convention | D03_S03_[Orientation][ele]deg[azi].wav
Example: D03_S03_Landscape_000deg_000deg.wav | | Sample rate | 48 kHz | | Bit depth | 16-bit | | Audio format | .wav | | Recording duration | 35.4s per file | | Number of channels | 4 channels (ch1=mic1, ch2=mic2, ch3=mic3, ch4=mic4) |

2.3 Recording Angles

The recordings cover the following angular positions:

• Azimuth: 0° to 360° in 15° increments [0°:15°:360°)
• Elevation: 0°

2.4 Database Access

The database is available for download at:

• Link: https://kpan.mioffice.cn/webfolder/ext/zh%24DE%24XejVH%24uVm31GQvyw%40%40?n=0.8984176924099081
• Password: 0x7o

3. Conclusion

The draft database for Device Type 3 is submitted for review. The current submission includes recordings in landscape orientation only. The remaining recordings, including table-mounted and portrait orientations, will be proposed based on meeting agreements. The completed version will be processed for future updates to DaCAS-1.

References

• [1] S4-252071: PDoc DaCAS-2_v0.5
• [2] S4-252026: DaCAS-1 Target devices and databases v0.4

Summary of S4-260124: Complexity Evaluation of DaCAS Example Solutions

1. Introduction and Background

This contribution from Bytedance addresses the complexity evaluation framework for DaCAS (Data Collection for Audio Scene) example solutions. The document recognizes that different example solutions will exhibit varying computational complexity due to differences in algorithms, number of channels, metadata amounts, and output formats. While the current DaCAS pdoc-3 includes complexity analysis as an optional component, this paper proposes making it a documented requirement.

2. Main Technical Contributions

2.1 Rationale for Complexity Analysis

The document establishes two key justifications for requiring complexity reporting:

• Feasibility Assessment: Provides fundamental information on compute and/or latency costs, enabling evaluation of whether an example solution can fit specific hardware/CPU constraints or operate in real-time
• Documentation Completeness: Enhances the sufficiency of example solution deliverables

2.2 Evaluation Procedure

Building on agreements from post-#134 telcos regarding self-evaluation of example solution performance, the proposal establishes that:

• Complexity analysis should be conducted alongside the self-evaluation process
• The proponent of each example solution is responsible for performing the complexity evaluation
• Proponents must provide sufficient documentation covering both the test procedure and obtained results

2.3 Metrics and Requirements Framework

The document proposes a flexible, non-comparative approach:

• No Minimum Requirements: No complexity threshold is established at this stage
• No Exclusion Criteria: Example solutions will not be rejected based on complexity
• No Cross-Comparison: Complexity results across different example solutions will not be compared
• Proponent Freedom: Proponents may select complexity metrics and test conditions at their discretion

2.4 Documentation Requirements

The proposal identifies key factors affecting complexity measurements that should be documented:

• Complexity metrics used
• Processing architecture (e.g., CPU, aDSP, NPU) and specific hardware model
• Software environment: Programming language, optimization level, and compiler
• Algorithm configurations: Filter length, encoder dimension, numerical precision of data

Proponents must document the selected complexity metrics along with sufficient detail on test conditions in the example solution deliverable.

3. Proposal for Agreement

The document proposes that SA4 agree that:

• Complexity analysis of example solutions should be conducted using metrics chosen by the proponent
• Results must be documented with sufficient detail in the deliverable submission

Work Plan for Diverse Audio Capturing System for UEs (DaCAS)

Introduction

This document presents the work plan for the DaCAS (Diverse audio CApturing System for UEs) work item, which was agreed at SA4#130 (S4-242262) and approved at SA#106 (SP-241962). The output will be TS 26.533 specification.

Timeline and Key Milestones

SA4#131 (Geneva, February 17-21, 2025)

Initial Framework Establishment: - Agreement on DaCAS work plan - Begin definition of potential target devices - Agreement on initial template for potential target devices - Begin definition of minimum performance requirement/objective criteria for raw/compensated microphone signals - Begin definition of requirements for signals for common database - Agreement on template for setup of recording scenarios - Agreement on initial template for common database, including legal framework for copyright issues - Begin discussion of performance requirements and performance evaluation methodologies for example solutions - Begin discussion of deliverables of example solutions - Begin collection of potential target devices

Telco-1 (March 10, 2025)

Template Progression: - Progress templates for potential target devices, recording scenarios, and common database - Continue collection of potential target devices

Telco-2 (March 31, 2025)

First Target Device Definition: - Agreement on definition of first target device(s) based on template - Revision of templates for potential target devices and common database - Continue collection of potential target devices - Begin work on legal framework for database

SA4#131-bis-e (April 11-17, 2025)

Version 1.0 Templates and Legal Framework: - Agreement on three templates version 1.0 - Legal framework for common database for legal review - Agreement on new potential target devices - Begin collection of common databases for first target devices - Continue work on performance requirements, evaluation methodologies, and collection of potential target devices

Telco (April 28, 2025)

Framework Agreements: - Continue collection of common databases for first target devices - Agreement on legal framework for common database - Agreement on three templates version 2.0 - Agreement on minimum performance requirement/objective criteria for raw microphone signals - Agreement on requirements for signals for common database - Begin verification of common database proposals for first target devices

SA4#132 (Fukuoka, May 19-23, 2025)

Initial Specification Versions: - Continue updates for templates, databases, and requirements - Agreement on common database for subset target devices - Agreement on three templates for collecting basic common database - Agreement on permanent documents version 0.1 for target devices, databases, test methods and requirements - TS 26.533 version 0.1.0

Telco (June 16, 2025)

Database and Test Method Development: - Continue collection of common databases - Definition of minimum performance requirements for raw microphone signals - Definition of test methods for example solutions - Definition of performance requirements for example solutions - Package definition of example deliverables - Agreement on collection of legal text for common databases

SA4#133-e (July 18-25, 2025)

Test Method and Requirements Refinement: - Continue definition of test methods for example solutions - Updates of TS 26.533 - Common databases of target devices - Definition of minimum performance requirements for raw microphone signals - Definition of mandatory recording scenarios

Telco (September 15, 2025)

Requirements Agreements: - Continue work on test methods, TS 26.533 updates, databases, and package definitions - Agreement on minimum performance requirements for raw microphone signals - Agreement on definition of mandatory recording scenarios

Telco (October 27, 2025)

Continued Development: - Continue work on test methods, TS 26.533 updates, databases, performance requirements, and package definitions

SA4#134 (November 17-21, 2025)

Example Solutions Development: - Continue work on common database for target devices - Deliverables of example solutions for target devices - Evaluation process for example solutions (TS 26.533), binary interfaces - Work on DaCAS-1, DaCAS-2, DaCAS-3

Telco (December 9, 2025)

Example Solutions Continuation: - Continue work on common database, deliverables of example solutions, and DaCAS-1/2/3

Telco (January 13, 2026)

Pre-Submission Phase: - Continue work on common database and DaCAS-1/2/3 - Discuss deliverables of example solutions - Indications to submit example solution(s) - Indications to perform evaluation and verification of example solution(s)

SA4#135 (India, February 9-13, 2026)

First Major Milestone: - Continue work on common database, evaluation procedure and framework, example solution deliverables, and DaCAS-1/2/3 - [Submission of example solution(s) for target devices] - Begin evaluation and verification - Agree on TS 26.533 v1.0.0 to be sent to SA plenary for information

SA#111 (Japan, March 10-13, 2026)

Plenary Presentation: - Present Draft TS 26.533 v1.0.0 for information - Continue work on common database and DaCAS-1/2/3 - Agreement on evaluation procedure and framework - Agreement on example solution deliverables - Indications to submit and evaluate example solutions

SA4#135-bis-e (April 13-17, 2026)

Example Solutions Collection: - Start collection of example solutions - Continue evaluation results and report - Begin drafting of example solution(s) that meet performance requirements - Begin crosschecking example solutions by interested proponents

SA4#136 (Montreal, May 11-15, 2026)

Example Solutions Finalization: - Finalize collection of example solutions - Review verification results - Continue crosschecking - Agreement on example solution specifications - Continue drafting of example solutions - Agree on TS 26.533 v2.0.0 to be sent to SA plenary for approval

SA#112 (Singapore, June 9-12, 2026)

Approval Milestone: - Present TS 26.533 v2.0.0 for approval

SA4#137-bis-e (August 24-28, 2026)

Verification Continuation: - Review verification results - Continue crosschecking and drafting of example solutions - Agree on TS 26.533 v1.0.0 to be sent to SA plenary for information

SA#109 (Beijing, September 16-19, 2026)

Plenary Information: - Present TS 26.533 v1.0.0 for information

SA4#138 (Calgary, November 16-20, 2026)

Final Specification: - Agreement on example solution specifications - Agree on TS 26.533 v2.0.0 to be sent to SA plenary for approval

SA#110 (Baltimore, December 9-12, 2026)

Final Approval: - Present TS 26.533 v2.0.0 for approval

Main Goals of the Work (Annex A)

Overall Intention

Provision of immersive audio capture normative example solutions to speed up deployment of a fully end-to-end IVAS ecosystem.

Part 1: Target Device and Database Definition

Target Device Specifications: - Definition of a set of target devices or target device types - Definition of minimum performance requirement/objective criteria for raw microphone signal performance and characteristics - Definition of requirements for signals based on target devices or target device types - Collection of a set of target devices or target device types - Collection of common database for target devices

Part 2: Example Solutions Development

Solution Development and Evaluation: - Development of immersive audio capture example solutions for target devices - Evaluation of available immersive audio capture example solutions based on relevant sending side terminal audio quality test methods defined in TS 26.260 - Verification and potential revision of minimum performance requirements based on example solution performance under TS 26.260 test methods - Specification of suitable example solutions - Potential alignment with TS 26.260 and 26.261

DaCAS Example Solution Input Requirements

Minimum Input Requirements: - Raw/compensated microphone signals - Target device configuration information (TBD) - Capture configuration parameters (TBD)

Open Issues: - Note 1: Clarifications required on required/optional raw microphone compensation - Note 2: If microphone compensation is required/provided, clarification required whether example solution can use both raw and compensated microphone signals or only compensated signals

Notes

The time plan defines milestones for first target device(s). Parallel development of additional target devices can have corresponding milestones later than indicated in this plan.

Comprehensive Summary of 3GPP Technical Document on DaCAS-3 Deliverables

Document Overview

This is a permanent document (pdoc) v0.21 serving as a tracking mechanism for defining Data-driven Channel-Adaptive Spatial Audio (DaCAS) example solutions and their deliverables. The document provides the structural framework that will feed into TS 26.533.

Main Purpose

The document establishes a standardized template for documenting DaCAS example solutions, ensuring consistency across contributions from different sources. It functions as a living document where agreed contributions will be integrated over time.

Technical Framework Structure

2.1 Example Solution Template

The document provides a comprehensive skeleton structure for future example solution contributions. This template ensures all solutions are documented with consistent information categories.

2.1.1 Supported Target Devices

• Placeholder for listing indices of supported target devices
• Currently TBD (To Be Determined)

2.1.2 Supported Output Formats

• Intended to specify output format types (e.g., SBA - Scene-Based Audio, ISM - Image Source Method, etc.)
• Currently TBD

2.1.3 High-level Description

2.1.3.1 Input Interfaces - Placeholder for describing input interface specifications - Currently TBD

2.1.3.2 Data - Distinguishes between two solution types: - Neural-network-based solutions: Requires description of training data used to develop the solution - Signal-processing-based solutions: Requires description of necessary data (e.g., geometric data of target devices) - Currently TBD

2.1.3.3 Processing Procedure - Should include descriptions of: - Offline signal processing procedures - Online signal processing procedures - Model structure (for ML-based solutions) - Currently TBD

2.1.4 Algorithmic Description

• Placeholder for detailed algorithmic description of the example solution
• Currently TBD

2.1.5 Source Code

The document establishes different requirements based on solution type:

For signal processing-based solutions or modules: - Source code of the algorithm must be included in the example solution package

For neural-network-based solutions or modules: - Final checkpoint (trained weights) must be provided - Inference code must be provided - Training code and intermediate checkpoints are optional

2.1.5.1 Usage Guideline - Should contain instructions on how to compile, run, and test the code - Currently TBD

2.1.6 Test Vectors

• Placeholder for test vector specifications
• Currently TBD

2.1.7 Evaluation and Verification Results

2.1.7.1 Objective Evaluation Results - Placeholder for objective metrics and results - Currently TBD

2.1.7.2 Subjective Evaluation Results - Optional section for subjective test results - Currently TBD

2.1.8 (Optional) Complexity Analysis

• Optional section for analyzing computational complexity of the example solution
• Currently TBD

2.1.9 (Optional) Algorithmic Delay Analysis

• Optional section for analyzing processing delay characteristics
• Currently TBD

2.1.10 Legal Framework

• Should contain necessary legal declarations for solution providers to share the content
• Ensures IPR and licensing considerations are addressed
• Currently TBD

Key Technical Contributions

Standardization Framework

The main contribution is establishing a unified documentation framework that: 1. Accommodates both neural-network-based and signal-processing-based solutions 2. Ensures reproducibility through mandatory source code/model sharing 3. Requires comprehensive evaluation (objective and optionally subjective) 4. Addresses practical implementation aspects (usage guidelines, test vectors) 5. Includes optional performance analysis sections (complexity, delay) 6. Incorporates legal framework considerations

Flexibility in Solution Types

The template explicitly supports two paradigms: - Data-driven (ML-based) approaches: With specific requirements for trained models and inference code - Traditional signal processing approaches: With requirements for algorithmic source code and geometric data

Deliverable Requirements

Clear distinction between mandatory and optional deliverables ensures baseline comparability while allowing flexibility for additional information.

References

The document builds upon: - S4-250963: "Proposal for DaCAS deliverables" (Nokia) - S4aA260009: "[DaCAS] Example solution deliverables" (Bytedance, Beijing Xiaomi Mobile Software)

Current Status

This is a template document (v0.21) with all technical sections marked as TBD, awaiting contributions from participants to populate the framework with actual example solutions.

Summary of S4-260218: Proposed Changes to Example Solution Deliverables

1. Introduction and Context

This contribution from Fraunhofer IIS and Dolby Laboratories proposes modifications to the example solution deliverables list for the DaCAS (Diverse audio Capturing System for UEs) work item. The document builds upon the candidate list of example solution deliverables previously specified in S4aA260009.

Key Rationale

• Development of immersive audio capture example solutions is a main objective of DaCAS according to the WID (SP-241962)
• Example solutions are not mandatory and thus not relevant for interoperability
• Example solutions serve primarily as proof of feasibility rather than normative implementations
• Deliverables should be restricted to what is necessary to ensure plausibility and reproducibility

2. Main Technical Contribution

Proposed Streamlined Deliverables List

The document proposes that example solution deliverables should include the following components:

1. List of target device(s) supported

2. High-level description of data used to develop the example solution

3. List of supported output format(s)

4. High-level algorithmic description

5. Executable or library with API (Windows or Linux), including:

6. Guide on how to compile (if applicable)

7. Guide on how to run

8. Report of evaluation results, following at minimum:

9. Test methodologies specified in DaCAS-2 and DaCAS-3

10. Evaluation scenarios specified in DaCAS-2 and DaCAS-3

11. Legal framework (if any) necessary by the solution provider to share the content (e.g., user license for the example solution)

12. Supplementary information

Key Simplifications

The proposed changes appear to emphasize: - High-level descriptions rather than detailed technical documentation - Focus on algorithmic description and dataset description at a conceptual level - Practical implementation artifacts (executable/library) with usage guidance - Evaluation results aligned with DaCAS test methodologies

3. Conclusion and Next Steps

The document proposes that these modified example solution deliverables be included in the DaCAS-3 permanent document.

The streamlined approach aims to balance the need for proof of concept demonstration with practical considerations around what is necessary for validation and reproducibility of immersive audio capture capabilities.

DaCAS-2: Test Methodologies and Requirements v0.56

Document Overview

This document defines test methodologies and requirements for Device-Assisted Capture Audio Systems (DaCAS) as part of the DaCAS Work Item. It is structured around four main objectives: defining minimum performance requirements for raw microphone signals, evaluating immersive audio capture example solutions, verifying/revising requirements based on example solution performance, and potential alignment with TS 26.260 and 26.261.

Requirements for Raw and Compensated Microphone Signals

Raw Microphone Signals

The document proposes requirements and recommendations for raw microphone signals (Table 1), covering:

• Frequency Response: Minimum captured frequency should be below 100 Hz (-3dB point), with flat response above minimum frequency and below resonances
• Resonances: Shall be above 6 kHz (should be above 8 kHz)
• SNR: Shall be at least 54 dB (should be at least 60 dB)
• Sensitivity: Recommended level below -25 dBFS (±1 dB) with 1 kHz sine signal @ 94 dB SPL
• Directivity: Recommended omnidirectional characteristics with clear documentation
• ADC Bit Depth: Shall be at least 16 bits (should be 24 bits)
• Acoustical Overload Point: Shall be at least 120 dB SPL @ 10% THD (should be 130 dB SPL)

Editor's Note: Decision needed on normative vs. informative requirements.

Compensation on Microphone Signals

Compensation is considered optional for example solution development. If proponents provide compensated signals, they shall provide: - Compensation filter specifications with relevant data - Instructions on filter application to raw microphone signals

Compensated Microphone Signal Requirements

Table 2 defines requirements for compensated signals: - Compensated Frequency Response: Must be within required/recommended masks (Tables 3-4) when applied to signals used for filter design - Phase Properties: Should compensate sound source direction-independent phase differences - Masks defined for frequencies 100 Hz to 16 kHz with tighter tolerances in recommended vs. required masks

Compensation Processing Methods

Diffuse Field Based Compensation Method

Integrated from S4aA250054, this method includes:

Derivation of Compensation Filters

Recording Environment Requirements: - Quiet room with low reverberation - 7.1.4 surround loudspeaker layout (or known layout with front/rear/side/height differentiation) - Diffuse uncorrelated pink noise signals (omitting subwoofer) - Device positioned landscape orientation, camera toward center speaker - 10 seconds noise recordings + 15 seconds silence for noise floor estimation

Processing Steps: 1. Gain Matching: Derive broadband relative gain G(ch) per channel to align outlier microphones 2. Equalization Estimation: - Model theoretical impulse responses from device geometry - Create simulated device microphone signals - Compare simulated vs. real recordings to estimate port resonance equalization - Calculate: port(ch,f) = sim(ch,f) – dev(ch,f) - Convert to banded spectrum and model resonances parametrically 3. Noise Floor Estimation: Generate banded per-channel noise floor estimate NF(ch,b) from silence recording

Compensation Processing (DFT domain): - Convert input DFT to banded spectrum spec(ch,b) - Calculate noise floor compensation gains: g(ch,b) = (spec(ch,b) – NF(ch,b))/(spec(ch,b) + eps) - Apply combined gain: G(ch) * EQ(ch,f) * g(ch,f)

Editor's Note: Clarification needed on linear vs. log scale for applied gain and method status.

IMPro Method

Integrated from S4aA260008, based on Integrated Microphone Pressure frequency response measurement:

IMPro Calculation

Integrated microphone pressure frequency response calculated by:

Equation (1): Dividing measured integrated microphone output signal response by probe signal output response at reference point at sound port inlet, with probe microphone calibration

Compensation Filter Target Response

For M microphones, compensated output defined as convolution of raw signal with equalization filter. Target equalization filter compensates integrated microphone response within target frequency response mask to correspond to delayed pressure signal at sound inlet.

Equation (2): Target frequency response in frequency domain within target mask range

Proposed Calibration Method

Steps: 1. Perform IMPro measurements for all device microphones 2. Prepare UE software for raw microphone recording 3. Setup loudspeaker and device (0.5-2m distance) 4. Prepare sine sweep stimulus (~30dB above background noise) 5. Calibrate probe microphone(s) 6. Perform IMPro measurement (pressure at sound inlet + DUT recording) 7. Time-align signals 8. Calculate integrated microphone pressure frequency response per microphone 9. Design linear equalization filters to align responses within masks 10. Implement equalization filters in UE software 11. Process raw signals with equalization filters 12. Verify compensated signals satisfy frequency response mask requirements

Evaluation Procedure

Integrated from S4aA260008, the evaluation procedure includes:

Overview

• Self-evaluation approach for example solutions (mandatory)
• Optional cross-evaluation on best-effort basis by interested proponents with relaxed documentation guidelines
• High-level documentation guidelines followed
• At least informal assessment against TS 26.261 requirements

Self-Evaluation Procedure

1. Proponent processes recordings with example solution
2. Proponent performs objective evaluation using DaCAS-2 evaluation scripts
3. Subjective evaluation recommended (methods TBD)
4. Detailed documentation of procedure and results provided

Optional Cross-Evaluation

• Any 3GPP member company may evaluate one or more example solutions
• Cross-evaluation lab runs evaluation script with example solution output signals
• May evaluate provided processed signals or run solution with recordings
• Detailed documentation of procedure and results provided

Editor's Note: Clarification needed on cross-evaluation scope, documentation in specification, and minimum dataset.

Documentation Guidelines

Evaluation reports shall include: - Target device(s) used - Description of example solution input signals - Details on output signals including IVAS input format(s) - Example solution output signals (provided) - Evaluation considering IVAS input format characteristics - Evaluation results and observations

For self-evaluation, additional tests for realistic scenarios not covered in TS 26.260 may be included with full documentation and recording availability.

Test Methodologies

Objective Test Methodologies

Recording Setups and Scenarios

Single Source Scenario (Table 1): - Sound Source: High-quality loudspeaker compliant with TS 26.260 clause 4.0.2 - Source Signal: British English single talk (ITU-T P.501), Male/Female, 20Hz-20kHz, 35.4s, -27 dB RMS, 48 kHz, 16-bit - Calibration: 75 dB SPL playback, equalized spectrum within ±1 dB (100-200 Hz) and ±0.5 dB (200 Hz-20 kHz) - Acoustic Environment: Anechoic chamber OR acoustically treated room (ETSI TS 103 224 or ITU-T BS.1116 compliant) - Positioning: - Hand-held/Headset: 1-1.5m distance, elevation 0° - Table-mounted: per TS 26.260 clause 5.4.2.5, elevation 26.6° - Azimuth angles: 0°, ±30°, ±60°, ±90°

Multi-Source Scenario for ISM Evaluation (Tables 2):

Recording procedure: 1. Record sound sources individually (reference signals) 2. Sum individual recordings to obtain final input signals

Scenario X-1 (Table-mounted): - UE lying flat on table, screen up - Source distance: 0.5-1m (equal for both sources) - Source height: 0.4m relative to UE - Azimuth angle combinations: [-90°, 90°], [-110°, 70°], [-110°, 90°] - Overlap pattern: source 1 only (25%) → source 2 only (25%) → both sources (50%) - Applicable only for smartphone-type devices

Scenario X-2 (Hand-held): - UE in hand-held landscape orientation, screen toward sources - Source distance: 0.3-0.5m (equal for both sources) - Source height: 0m relative to UE - Azimuth angle combinations: [-30°, 30°], [-45°, 45°], [-30°, 45°] - Same overlap pattern as X-1 - Applicable only for smartphone-type devices

Test Methods

Delay: - Assess algorithmic delay only (input to example solution → output signal) - Mitigates testing inaccuracies and acoustic path impact - Dependencies on platform where example solution runs recognized

Loudness: - Use recordings from single source scenario (azimuth=0°, elevation=0°) - Process with example solution - Analyze according to TS 26.260 clause 5.6.2 - Editor's Note: ITU-R BS.1770/P.700 via binaural rendering under consideration (pending ATIAS discussion)

Frequency Response:

For Stereo, SBA, MASA capture: - Use recordings from single source scenario (azimuth=0°, elevation=0°) - Process with example solution - Analyze according to TS 26.260 clause 5.6.3

For ISM capture: - Use recordings from scenarios X-1 and X-2 - Process with example solution - For each object, calculate frequency response per TS 26.260 clause 5.6.3.2 using corresponding individual sound source recording as reference

Directional Information: - Based on TS 26.260 clause 5.6.4 for Stereo, SBA, MASA formats - Assessment directly on example solution output (excluding transmission assumptions) - Use recordings from single source scenario for all defined sound source directions - Process with example solution - Compute directional measurement and metric per TS 26.260 clause 5.6.4 - Editor's Note: For other formats, intermediate rendering to supported format via IVAS reference renderer could be considered

Test Script for Objective Evaluation

General: - Programming language: Python - Available at: forge.3gpp.org/rep/sa4/audio/dacas - Editor's Notes: - Licensing, requirements, environment to be added - Missing components (database reading, loudness test rendering, final report generation, reference signal handling, format support) to be added after DaCAS-2 details finalized - Updated version to be uploaded to Audio subgroup repo

Core Functions: - read_wav_file: Read WAV files (16-, 24-, or 32-bit depth); PCM support may be added - estimate_delay_whole: Calculate delay between channels across whole signal (based on TS 26.260 Annex C) - p56_active_level: Estimate speech active level (ITU-T P.56) - compute_panorama: Estimate stereo panorama (TS 26.260 methodology) - frequency_response: Compute 1/12-octave bandwidth spectrum (ISO-3 R40, 100 Hz-12 kHz) - p79_slr: Compute Send Loudness Rating (TS 26.260)

Editor's Notes: - Format support to be added - IVAS reference renderer to be added - Decision needed on ITU-R BS.1770/P.700 via binaural rendering

Processing Approach: - Example solutions process recording database into IVAS input format files with optional metadata - Scripts read entire audio signal, convert to floating-point, perform offline evaluations - Current version includes stereo directional information analysis support

Subjective Test Methodologies

Section placeholder - content TBD for: - Test conditions - Recording setups and scenarios - Recording database - Test methods

Requirements

Requirements for Objective Test Methodologies

Placeholders for requirements on: - Delay - Loudness - Frequency response - Directional information

Requirements for Subjective Test Methodologies

Content TBD

Revision History

• v0.1 (2025-05-22, SA4#132): Initial version
• v0.2 (2025-06-16, Audio SWG AH): Added compensation method and single source recording scenario
• v0.3 (2025-07-22, SA4#133-e): Added agreed content from multiple contributions
• v0.4 (2025-11-17, Audio SWG AH): Added agreed content on IMPro method
• v0.5 (2025-11-19, SA4#134): Added agreed content and test script descriptions
• v0.6 (2026-02-08, Audio SWG AH): Added agreed content on evaluation procedure

Summary of S4-260236: Device Microphone Array Characterization

Introduction and Motivation

This contribution addresses the characterization of UE microphone arrays, proposing an extension to the IMPro (Integrated Microphone Pressure frequency response) method to handle devices with non-identical microphone integrations. Traditional anechoic chamber measurements are time-consuming and require laboratory automation. The IMPro method combined with numerical acoustic modeling offers a more flexible alternative, but practical challenges arise when microphone integrations differ across the array.

The key technical challenge is that when microphones have different port lengths, cavity shapes, meshes, or ingress-protection structures, the relative inter-channel propagation delay (RIPD) between microphones can vary. This is particularly problematic when measurement devices are not accurately synchronized with the UE's audio clock, which can affect spatial audio algorithms that rely on relative timing information.

Factors Affecting Microphone Integration Variation

The document identifies multiple factors that can cause integrated microphone characteristics to vary within a single UE:

• Device shape and surface curvature around sound inlets
• Mixture of different microphone transducer types
• Device hardware mechanics and PCB layout
• Ingress protection meshes and gaskets
• Microphone inlet integration in earpiece or loudspeaker outlets
• Protection against user misuse

Experimental Validation

Test Setup

The source conducted experiments using: - A simplified microphone integration jig with removable tubes of different lengths (5mm, 7mm, 8mm, 10mm) - An array of commercial and custom-built probe microphones - Analog transducers enabling accurate synchronization

Case Study: DoA Estimation Error

A case study was performed using DaCAS target Device B geometry with microphone positions #1-#4: - Microphone port lengths: #1: 8.0mm, #2: 8.0mm, #3: 5.0mm, #4: 7.0mm - DoA estimation performed using GCC-PHAT method - Device aligned in landscape orientation in horizontal plane - Direction estimation analyzed at 1-degree resolution across 360 degrees

Results: The largest DoA errors occurred towards both ends of the device in landscape orientation, demonstrating the impact of varying microphone port lengths on spatial audio algorithm performance.

Proposed Technical Solution

Extension to IMPro Method

The contribution proposes extending the IMPro method defined in the DaCAS-2 permanent document with the following technical framework:

2.1-2.2 IMPro Method Baseline

The integrated microphone pressure frequency response H_m(f) is calculated by:

H_m(f) = Y_m(f) / [X_p(f) · C_p(f)]

where: - Y_m(f): measured integrated microphone output signal response - X_p(f): probe signal output signal response at reference point at sound inlet - C_p(f): calibration frequency response of probe microphone

2.3 Compensation Filter Target Response

Key definitions: - M: number of device microphones - p_m(t): pressure at m-th microphone sound inlet - h_m(t): impulse response of integrated microphone using IMPro - g_m(t): equalization filter for microphone signal compensation - y_m(t): raw microphone signal output - z_m(t): compensated microphone output

The compensated microphone output is defined as: z_m(t) = g_m(t) * y_m(t)

The target equalization filter response compensates for integrated microphone response such that: z_m(t) = p_m(t - τ_m)

In frequency domain: G_m(f) = e^(-j2πfτ_m) / H_m(f)

within the range of target frequency response mask.

2.4 Proposed Integrated Microphone Calibration Method

The calibration procedure consists of four main steps:

Step 1: Perform IMPro measurements for all device microphones - Prepare UE software for raw microphone recording - Setup loudspeaker and device at 0.5-2m source distance - Prepare measurement stimulus (sine sweep) at ~30dB above background noise - Calibrate probe microphone(s) - Perform IMPro measurement with probe at sound inlet while DUT records - Time-align measured audio signals - Calculate H_m(f) for each microphone

Step 2: Calculate compensation filter - Measure H_m(f) from reference sample or average from multiple devices - Design linear equalization filters according to equation (2) - Ensure responses align within equalization filter frequency response mask and difference mask

Step 3: Implement equalization filter in UE software - Process raw microphone signals y_m with filters g_m to produce compensated outputs z_m

Step 4: Verify compensated microphone output - Check all microphone signals satisfy equalization filter frequency response mask (target timbre) - Check all signals satisfy equalization filter frequency response difference mask (spatial information preservation) - Verify z_m(t) is effectively a delayed version of pressure signal at sound inlet with constant delay τ_m

2.5 Applicability Condition for Synchronized IMPro Measurement

Key Technical Requirement: If the UE employs non-identical microphone integrations (different acoustic port lengths, meshes, gaskets, baffles, or cavity geometries) such that inter-microphone propagation delay differences may be non-negligible, the IMPro measurement must address the RIPD.

This requirement is fulfilled by either:

1. Synchronized IMPro acquisition: All probe signal(s) and all UE microphone signals acquired with shared, repeatable time base, OR

2. IMPro acquisition with probe-array: Simultaneous probe measurements at all relevant inlets during UE recording

For probe-array approach: - Requires calibrated probe microphones calibrated simultaneously to common reference - Preferably single multichannel recording with as many probes as UE microphones - Enables inspection of probe positioning for all microphones before measurement - Alternative: sequential approach with reference microphone for synchronization (requires ensuring no setup changes during microphone movement)

NOTE: This clause does not alter the IMPro calculation or compensation target defined in sections 2.2 and 2.3.

Conclusion

The source proposes extending the IMPro-based compensation method defined in the DaCAS-2 permanent document with the presented synchronized measurement approach. This enables accurate isotropic characterization of UE microphone arrays even when the measurement device does not guarantee accurate synchronization with the UE audio clock, particularly for devices with significantly different or unknown microphone port integrations.

Summary of S4-260244: Status of the Target Device Databases

Introduction

This contribution reviews the current status of target device databases for the DaCAS-1 (Device-Agnostic Capture Audio Scene) work item. The document identifies gaps in the existing recording databases and proposes minimum requirements and timelines for completing the database collection to enable successful example solution development and evaluation.

Current Database Status

Recording Coverage Analysis

The document presents a comprehensive status table showing the availability of recordings across five target devices (A_device_A, A_device_B, B, C, D, E) and ten recording scenarios (RS 1-10):

Target Devices: - Device A (two variants): Four-Microphone Prototype devices - Device B: Three-Microphone Smartphone device - Device C: Four-Microphone Smartphone device 1 - Device D: Four-Microphone Smartphone device 2 - Device E: Three-Microphone XR HMD device

Recording Scenarios (as defined in [1]): 1. SNR recordings 2. Rotational sweeps 3. Evaluation recordings based on TS 26.260 4. Fixed single talker 5. Moving single talker 6. Fixed multiple talkers 7. Fixed talker(s) and fixed music source 8. Moving single talker and moving music source 9. ISM frequency response 1 10. ISM frequency response 2

Key Findings

• Most devices only have recordings for scenarios 1 and 2 available
• Device A variants have the most comprehensive coverage (RS 1-8)
• Devices B, C, and E only have RS 1-2 recordings
• Device D has RS 1-2 and RS 4 recordings

Identified Issues and Concerns

The contribution highlights several critical limitations of the current database status:

1. Insufficient for Example Solution Development: The limited recordings (primarily RS 1-2) are adequate for device characterization but insufficient for developing, fine-tuning, and evaluating potential example solutions

2. Lack of Real-World Scenarios: Absence of recordings in real immersive usage scenarios with real (moving) talkers hinders example solution development and may result in varying quality across different target devices

3. Limited Evaluation Capability: Current database limitations prevent:

4. Subjective evaluation (even informal)
5. Successful self-evaluation
6. Optional cross-evaluation

Proposed Minimum Recording Set

Required Recordings

The document proposes the following minimum set for agreement:

1. Recording scenarios 1, 2, and 3 as defined in [1]
2. At least 2 recordings of real immersive usage scenarios (e.g., based on recording scenarios 5-8)

Recommended Recordings

For more comprehensive coverage:

1. At least 4 recordings of real immersive usage scenarios (based on RS 5-8)
2. Preferably recordings of all recording scenarios defined in [1]

Proposed Timeline

• Deadline: SA4-136 meeting for completion of minimum recording set collection
• Near-term action: For Four-microphone Prototype devices, the source (Nokia) is preparing to share RS 3 recordings at upcoming Ad-hoc telcos

Conclusion

The contribution emphasizes the urgent need to extend target device databases beyond the currently available RS 1-2 recordings. The proposed minimum recording set and timeline aim to ensure sufficient data availability for successful example solution development, fine-tuning, and evaluation across all target devices in the DaCAS-1 work item.

Time Plan Proposal for DaCAS Work

Introduction

This contribution proposes a modified timeline for the Data Collection and Codec Adaptation Study (DaCAS) work item. The proposal is motivated by the agreement at SA4-134-2 Ad-hoc telco on a combined evaluation approach comprising: - Self-evaluation of submitted example solutions - Optional cross-evaluation

Since the evaluation requires sufficient time after example solution submission, and certain key milestones (e.g., deliverables) have not yet been agreed, the time plan needs to be updated accordingly.

Key Milestones Identified

The following milestones are considered critical for successful completion of DaCAS work:

1. Completion of database collection
2. Completion of evaluation framework definitions
3. Completion of example solution deliverables definition
4. Submission of example solutions
5. Evaluation of example solutions
6. Completion of specification

Proposed Timeline

SA4#135 India (February 2026)

• Continue further database collection
• Continue defining the evaluation procedure and framework
• Continue defining example solution deliverables

SA4#135-bis-e

• Continue defining the evaluation procedure and framework
• Continue defining example solution deliverables
• Continue further database collection

SA4#136 Montreal

• Complete database collection
• Complete defining evaluation framework
• Complete defining example solution deliverables
• Indications to submit example solution(s)
• Begin self-evaluation

SA4#137e

• Submission of example solution(s) for target devices
• Submission of processed example solution output signals for optional cross-evaluation
• Begin documentation of suitable example solution(s) in draft TS 26.533
• Begin optional cross-evaluation and verification
• Continue self-evaluation
• Agree on TS 26.533 v1.0.0 to be sent to SA plenary for information

Ad-hoc telco post-137e

• Submission of self-evaluation and optional cross-evaluation reports
• Begin specification of suitable example solution(s)

SA4#138 Calgary

• Complete specification of suitable example solution(s)
• Agree on TS 26.533 v2.0.0 to be sent to SA plenary for approval

Conclusion

The proposed timeline in Table 1 is recommended for agreement. This schedule allows sufficient time to: - Complete pending tasks - Reach necessary agreements before example solution submission - Conduct both self-evaluation and optional cross-evaluation - Progress from draft specification (v1.0.0 for information) to final specification (v2.0.0 for approval)

While certain aspects may be influenced by outcomes of upcoming meetings, all necessary progress should be achievable within the proposed schedule.

Determining Suitable DaCAS Example Solutions

Introduction

The DaCAS work item [1] aims to specify suitable example solution(s) for generating IVAS input formats. Several target devices have been identified with varying form factors and microphone placements. Given that the IVAS codec supports many input formats, a large number of example solutions are expected to be submitted. This contribution continues the discussion from [2] and proposes a way forward for determining suitable DaCAS example solutions.

Discussion

Progress on Evaluation Process

Good progress has been achieved in defining the evaluation process for DaCAS example solutions over past meetings, with potential completion at the current Goa meeting. The evaluation procedure is considered a key tool for determining the suitability of example solutions.

Documentation Requirements

Clarification is required on: - The detail level for example solution descriptions - Aspects to be included to enable specification in TS 26.533 - Initial proposals are provided in [2]

Definition of Suitability

Suitability of example solutions can be demonstrated by providing: - Agreed evaluation procedures - Appropriate documentation

In this context, suitability is understood as demonstrated feasibility that is sufficiently documented for reproducibility.

Proposal

Primary Proposal for Suitable Example Solutions

All example solutions which are evaluated, described, and documented according to procedures and level of detail agreed by SA4 prior to example solution submission will be included in an informative Annex of TS 26.533.

Suitability is therefore determined by: - Demonstration of feasibility - Provision of sufficient documentation

Future Enhancement Path

Within the DaCAS work item, or in future work (depending on timely completion of requirements in TS 26.261 as part of ATIAS_Ph3-MED), the documented/suitable example solutions can be further evaluated against an agreed set of requirements.

All example solutions that additionally meet the requirements defined in TS 26.261 will be specified (including the documentation of the test results) in TS 26.533 with informative status.

For these solutions: - Example solutions demonstrating suitability and meeting requirements would be moved from Annex to main body - Such solutions may be considered to have demonstrated a quality-level expected for services - Specifying these as recommended solutions may require provision of detailed algorithmic description and source code (which may not be required for all example solutions)

References

[1] SP-241962: "WID on Diverse audio Capturing System for UEs", SA WG4

[2] S4aA250141: "On specification of suitable DaCAS example solutions", Nokia

Summary of S4-260254: Proposed Update to Recording Scenario 3

Main Objective

This contribution proposes updates to recording scenario 3 in the DaCAS (Data Collection for Audio Systems) work to align with recent changes made to 3GPP TS 26.260 through the ATIAS_ph2 work item. The goal is to enable more consistent evaluation of DaCAS example solutions with the specifications in TS 26.260 and TS 26.261.

Background

Recent work documented in S4aA250123 proposed additional sound source angles for evaluating directional information, which led to updates in 3GPP TS 26.260. This contribution proposes reflecting similar changes in the DaCAS recording scenario 3 to maintain alignment between the two specifications.

Proposed Technical Changes to Recording Scenario 3

Sound Source Configuration

• Loudspeaker: High quality loudspeaker complying with clause 4.0.2 in TS 26.260
• Source Signal: British English single talk sequence per ITU-T P.501
• Male and Female speakers
• 20Hz-20kHz frequency range
• 35.4s duration
• -27 dB RMS level
• 48 kHz sample rate, 16-bit depth

Calibration Requirements

• Loudness: 75 dB SPL calibration according to clause 5.5.1 of TS 26.260
• Frequency Response: Equalized spectrum measured at 1m on-axis
• ±1 dB tolerance from 100-200 Hz
• ±0.5 dB tolerance from 200 Hz-20 kHz

Acoustic Environment

• Anechoic chamber (recommended per clause 4.0.3 of TS 26.260) OR acoustically treated room with short reverberation (compliant with ETSI TS 103 224 clause 6.1 or ITU-T BS.1116 clause 8)

Positioning Requirements (Key Changes)

For Hand-held and Headset devices: - Source distance: 1-1.5m - Source angles: According to Table 5 in Section 5.6.4.1 of TS 26.260 - Azimuth angles: 0°, ±30°, ±60°, ±90° - Elevation angle: 0°

For Table-mounted devices: - Source distance: 0.8-1.5m (aligned with clause 5.4.2.5 for Spatial capture arrangement in TS 26.260) - Azimuth angles: 0°, ±30°, ±60°, ±90°, ±120°, ±150° - Elevation angle: 26.6° (per clause 5.4.2.5 in TS 26.260)

Documentation Requirements

• Applied sound source, acoustic environment, and device mounting shall be clearly documented
• Depending on targeted capture capability, a subset of recorded sound source angles may be used for evaluation

Conclusion

The contribution proposes agreement on the updated recording scenario 3 to enable closer alignment between DaCAS evaluation procedures and the test methods specified in the latest release of 3GPP TS 26.260.