A Maximum Length Sequence–Based Method for Robust Round-Trip Latency Estimation in online Digital Audio Workstations

A Maximum Length Sequence–Based Method for Robust Round-Trip Latency Estimation in online Digital Audio Workstations J. M. Gil Panal Télécom Paris, Institut Polytechnique de Paris [email protected] Gaël Richard Télécom Paris, Institut Polytechnique de Paris [email protected] Aurélien David Télécom Paris, Institut Polytechnique de Paris [email protected] ABSTRACT Accurate estimation of latency when working with digital audio equipment is critical for the precise operation of certain applications. This is particularly true for Digital Audio Workstations (DAWs) and other tools used in the creation and editing of audio, especially music. These systems require exact synchronization or alignment of tracks, which is essential for the mixing process. Latency is an inherent phenomenon in audio capture and restitution. Although it may sometimes be minimal, it is always variable depending on the device, operating system, and audio configuration. The undesired effect introduced by latency—specifically referred to in this context as round-trip latency—manifests as a delay between the audio input and the corresponding output. The most effective way to address this issue is through prior measurement to enable proper compensation. Various methods exist for performing this measurement, generally based on the playback and recording of acoustic signals. This article presents an existing method applied in a novel way within the domain of audio and web browsers, based on the use of a Maximum Length Sequence (MLS) signal. This signal is commonly used in room impulse response characterization. To validate its effectiveness and identify the limitations of the proposed approach, multiple tests and experiments were conducted on different devices. Results were compared across various browsers and operating systems, and the proposed solution was benchmarked against the methods employed by existing online DAWs. The implementation of the proposed method is available as part of the Hi-Audio online platform—an open-source, browser-based DAW—providing a practical demonstration of its applicability and integration in real-world web audio environments. 1. INTRODUCTION In browser-based audio applications, and more generally in any software program such as DAW, regardless of the underlying operating system, round-trip latency refers to the total delay between the moment an input signal is received Licensed under a Creative Commons Attribution 4.0 International License (CC BY 4.0). Attribution: owner/author(s). Web Audio Conference WAC-2025, November 19–21, 2025, Paris, France. © 2025 Copyright held by the owner/author(s). and when the corresponding output signal is rendered or reaches the speakers [1, 2]. Round-trip latency adversely affects the temporal alignment of audio tracks and can be expressed as the sum of the input and output latency [3], i.e., roundtrip latency =input latency +output latency. Theoretically, the audio input and output latency should be constant, however in practice it may significantly vary with time due to the system adapting to the environment and changing its setup: energy saving, processing according to the background noise, etc. Input latency accounts for delays introduced by USB transmission, audio drivers, operating system scheduling, and is dependent on the audio buffer size used. Lower numbers for bufferSize [4] will result in a lower (better) latency. For example, with a buffer size of 128 samples and a sample rate of 44,100 Hz, the buffer latency is approximately 128/44100 ≈2.90 ms [5]. This value is available through the AudioContext baseLatency property. Output latency represents the time elapsed between the start of audio processing and the actual playback of sound. It can be estimated analytically using the AudioContext outputLatency property [6], a read-only attribute that provides an estimate of the output latency for the current audio context. Knowing these aforementioned properties can help sometimes to understand the behavior of the browser in certain scenarios, but can never be used as reference to compensate the undergoing round-trip latency in the recording, requiring from real audio measurements. A key challenge in music performance with DAWs is accurately measuring round-trip latency during recording to keep audio synchronized. Millisecond precision is needed for proper track alignment, as timing errors as small as 10 ms are audible in rhythmic contexts [7]. The estimation procedure typically involves capturing the system’s audio output (e.g., loudspeakers or headphones) via the input device (e.g., microphone), under the assumption that the two are co-located or very close and that the output signal is played at a sufficiently high volume. Existing systems have addressed this problem by employing predefined acoustic signals such as impulsive clicks or sinusoidal beeps [8, 9, 10]. However, these methods exhibit reduced robustness in acoustically adverse environments characterized by background noise or reverberation. Moreover, sinusoidal beeps can be perceptually intrusive or unpleasant, particularly when played at elevated sound pressure levels. 2. THE MLS APPROACH For the Hi-Audio online platform [11], a novel and more robust approach has been adopted for latency estimation, based on the use of a MLS sequence. MLS are pseudorandom noise signals characterized by an autocorrelation function that closely approximates a Kronecker delta, see figure 1, enabling accurate estimation of round-trip delay [12]. These periodic sequences were originally generated via maximal linear-feedback shift registers and were first introduced by Schroeder in 1979 for room impulse response (RIR) measurements [13]. Owing to their favorable properties, MLS remain a widely utilized technique in acoustic system identification. Figure 1: Graph showing the result of the cross-correlation between the original MLS signal and the same signal recorded with a delay of 4731 samples. A peak is observed at this value, indicating the delay, which corresponds to ≈107.3 ms = lag samples/fs,fs= 44.1kHz. In the case of this study a 1.5 seconds MLS is employed, offering an effective trade-off between computational complexity and estimation accuracy. To enhance the robustness of the MLS approach, the confidence of the round-trip delay estimation is further evaluated. This confidence is assessed by computing the following ratio: R= 10 log10 maxτ[C(τ)2] 1 NPN 1C(τ)2!(1) where C(τ) is the cross-correlation between the input and output signals at time lag τand Nis the number of samples of the cross-correlation (typically N= 22050 corresponding to 0.5sfor signals at 44.1kHz). In practice, a pre-defined fixed threshold set to +18dB is established to consider the test successful. This value was empirically chosen during a preliminary testing phase. 3. EXPERIMENTAL SETUP Due to the novelty of the developed method and the lack of references in the literature regarding the use of MLSbased techniques for round-trip latency estimation in web browsers, it was necessary to conduct experimental tests to evaluate its effectiveness across various platforms. This section describes the processes and methodology employed for experiments, which involved different browsers and devices to estimate round-trip latency. The experimentation was conducted in the recording studio of T´el´ecom Paris in two distinct phases. 1. Phase 1: A prototype based on the MLS method1, already integrated as part of the Hi-Audio online platform2, was used to calculate latency within browsers. The code was executed automatically one hundred consecutive times. The goal is not to study how results vary over time, but rather to gather a representative number of samples for a specific platform. From the collected data, the mean and standard deviation were computed, and a histogram was generated to facilitate analysis of the results. The objective was to identify which browsers and operating systems yielded the most stable results. For this purpose, the consistency of latency measurements is considered more critical than the absolute latency value. A consistent latency value is essential to ensure predictable browser behavior when performing a recording. If the measurement varies constantly then the browser is not reliable. 2. Phase 2: The browser with the most stable latency performance (Phase 1) was selected for recording MLS signals across several online DAW platforms (see appendix). The objective was to assess whether the MLS-based roundtrip latency estimation method yields consistent and accurate results across different systems. Crosscorrelation analysis was employed for this comparison. The procedure consisted of the following steps: (1) uploading and recording an MLS signal via headphones and the system’s built-in microphone; (2) performing latency calibration using each platform’s available method; (3) recording the MLS playback after calibration. The recordings were then downloaded and analyzed using a Python utility3, which computes cross-correlation between the original and recorded signals and visualizes the results. The analysis output is the delay, expressed in milliseconds (or samples), indicating any misalignment between the signals. The following conditions were maintained uniformly across both experimental procedures (Phases 1 and 2): •All devices were connected to a power source to prevent battery usage, which could affect system performance and introduce latency variations. •At the time of testing, all devices had a battery charge level between 90% and 100%. •Browsers and versions used: Chromium/Chrome/Edge 137, Safari 18.4, Firefox 139. •The only software running on each device was the web browser used for the test, ensuring that no background processes consumed system resources that could influence the measurements. •Similarly, only a single incognito or private browsing tab was open, running the test application, to minimize interference from other browser activity. •The device’s built-in microphone was used for all recordings and the same wired headphones were employed on all tests and devices. 1available at https://github.com/gilpanal/weblatencytest 2https://hiaudio.fr 3https://gist.github.com/gilpanal/ f6a64a8fe797190bba22123dfea29611 •Audio input and output levels were kept constant throughout the testing process and were not adjusted between trials. These levels were identical for all browsers on a given operating system.4 •On Windows systems, audio enhancements and thirdparty drivers (such as MaxxAudioPro) were disabled to prevent the introduction of echo cancellation or noise suppression filters, which could distort the measurement results. One aspect to consider in the round-trip latency estimation of the following experiment is the impact of the JavaScript scheduler. Since JavaScript operates on an event loop [14] whose variability is neither constant nor predictable, it can introduce jitter outside the audio domain. Consequently, immediate calls to audio APIs cannot be assumed to execute synchronously. Another important consideration with regard to the prototype settings is related to the so-called audio constraints [15]. Audio constraints are introduced by the browser, but can be controlled from the JavaScript code. When using the Web Audio API, applying certain constraints can introduce signal filtering operations that degrade input audio quality due to built-in processing aimed at eliminating echo, background noise, and other artifacts. These constraints are defined through a set of parameters applied when configuring the incoming audio stream using the getUserMedia method, which is responsible for accessing the microphone. Constraints allow disabling default browser settings such as automatic gain control. Audio constraints are primarily intended to enhance user experience in video conferencing scenarios, by attempting to suppress microphone pickup of audio coming from device speakers. However, for high-fidelity audio recordings, these constraints can pose significant limitations. Constraints can exist at two levels: browser-level and device-level, both of which may affect the quality of the captured audio signal. The following example shows how constraints and the getUserMedia method are used in the MLS-based prototype, with boolean variables explicitly set to false: const CONSTRAINTS ={ audio: {echoCancellation:false, noiseSuppression:false, autoGainControl:false, latency: 0, channelCount:1} } navigator.mediaDevices.getUserMedia(CONSTRAINTS) If echoCancellation is enabled, it suppresses the recording of the sound being played, thereby making accurate measurement impossible. Furthermore, the generation of pseudo-random noise signals may be negatively affected by the activation of the noiseSuppression constraint. The constraint channelCount, is not supported across all browsers [16]. This constraint allows to control and limit the number of audio input channels—particularly useful for 4In the case of Bandlab and WAM at Windows, for Phase 2 of the experiments, it was required to increase the output volume of the system to get a value from the latency test. devices with multiple microphones, such as certain smartphones and laptops. channelCount is set to 1 (mono) for reasons of efficiency, compatibility, and simplicity. The latency constraint [17], specified in seconds, controls the time elapsed from the initiation of audio capture (i.e., when a sound occurs in the real world) until the data becomes available for further processing. While higher latency may be acceptable in certain applications as a means to reduce power consumption, the value set for the experiment is 0. Although 0 is not achievable, this value signals to the browser that the lowest possible latency is desired, prompting the system to minimize it as much as the environment allows. Another parameter, which is not an audio constraint, and can be set to 0 to control the playback latency is the latencyHint [18]. It is at the browser’s discretion to interpret the number appropriately. For the case of study it is used as follows: const ac =new AudioContext({latencyHint:0}) 4. RESULTS AND DISCUSSION Table 1 presents the results of the experiments at Phase 1. The mean and standard deviation values are obtained from 100 consecutive executions of the round-trip latency test, measured on different web browsers and operating systems. Firefox demonstrated the most stable performance, with the standard deviation frequently being zero or near-zero. This indicates that the latency values remained consistent across trials, which is a desirable characteristic for achieving accurate latency compensation. In contrast, Chromiumbased browsers, such as Chrome and Edge, exhibited significantly greater variability, with standard deviations around 8 ms, particularly on systems such as Ubuntu, and Windows. Lastly, while Safari on macOS also exhibited good stability, the latency values were generally higher compared to those obtained with Firefox on the same system. Table 1: Round-trip latency results over 100 consecutive tests for different browsers and systems. The table reports the mean latency, standard deviation, and the corresponding minimum and maximum values in milliseconds (ms). System / Browser Mean (ms) Std. Dev. (ms) Min (ms) Max (ms) HP Ubuntu 22.04 Chrome 64.50 7.94 49.37 85.17 Chromium 64.15 8.21 41.41 76.44 Firefox 65.69 0.00 65.69 65.69 Lenovo Windows 10 Edge 60.82 6.06 55.23 96.00 Chrome 62.84 2.44 61.42 73.42 Firefox 104.65 0.00 104.65 104.65 MacBook Pro 2021 Safari 100.02 0.00 100.02 100.02 Chrome 52.33 1.14 49.98 52.88 Firefox 38.89 0.00 38.89 38.89 Figure 2 illustrates a representative case using a Lenovo laptop running Windows 10 and Microsoft Edge. The his- togram shows latency values ranging from a minimum of 55.23 ms to a maximum of 96 ms. With a fluctuation margin of approximately 40 ms it becomes challenging to ensure effective latency compensation. This is especially problematic since the latency test is not typically run continuously by the user, making the behavior and variability of delay difficult to predict. Figure 2: Histogram showing round-trip latency measurements obtained by executing the test 100 consecutive times in the Microsoft Edge browser on Windows. In Phase 2 of the experimentation, additional measurements were conducted using a MLS signal across various platforms. The objective was to compare the accuracy of audio recording before and after applying latency compensation via the proposed methods. To determine the exact latency correction applied, cross-correlation was subsequently performed between the original MLS signal and the corresponding recorded one. For the Windows system, a separate MLS signal at a sampling rate of 48 kHz was generated, as this is the native input sampling rate for that operating system. For Ubuntu and macOS, an MLS signal at 44.1 kHz was used. The platforms tested are listed in the table of the appendix; the only exception was Amped Studio on macOS, where testing was not possible due to a software error in the application. Firefox was chosen as the default browser for all tests on operating systems, based on its proven latency stability in Phase 1. In general, it was observed that Soundtrap exhibited similar behavior on all operating systems by applying latency compensation even before performing input calibration. Similarly, Amped Studio appeared to apply a default compensation—20 ms on Ubuntu and macOS, and 80 ms on Windows—as indicated in its settings. This behavior resulted in a lower initial latency measurement compared to equivalent values on other platforms. On Windows, it was necessary to increase the output volume of the system for the test signal to be detected during latency evaluation, in both Amped Studio and WAM-Online Studio. This highlights the robustness of the MLS approach, which is resilient to lower input gain. In WAM, even after applying latency compensation, a substantial delay remained, as the compensation factor appeared to target the difference between round-trip latency and output latency, rather than the full round-trip latency. On Ubuntu, the measured latency for Firefox appeared to be approximately 60 ms, consistent with default values obtained in Bandlab and Hi-Audio, and similarly in Amped Studio when accounting for its 20 ms default compensation. In Windows, the general latency value was approximately twice as high, around 140 ms, with Hi-Audio achieving the most accurate compensation, with only a 0.48 ms deviation. Another remark regarding Windows is the different value obtained in Phase 2 with respect to Phase 1 for Hi-Audio, which demonstrates that latency may differ over time, indicating that it is not fixed for a given browser and system. Finally, on macOS, Bandlab provided the closest latency estimation, with a deviation of 0.73 ms. Overall, Firefox on macOS demonstrated an approximate latency of 40 ms. One of the most significant issues observed involves the presence (or absence) of embedded audio processing features—such as echo cancellation or noise suppression—that may alter the playback or capture of the MLS sequence, thereby compromising the accuracy of the delay estimation. Additionally, the use of hands-free Bluetooth headsets presents an unresolved limitation. These devices typically employ different audio transmission protocols that involve lossy compression, which can substantially degrade the characteristics of the MLS signal [19], ultimately impairing its effectiveness for latency measurement. 5. CONCLUSION This paper has addressed the issue of round-trip latency in digital audio systems, along with the rationale and motivation for employing acoustic MLS signals for its correction. The MLS-based method has been proposed for direct application in the context of web audio, particularly in DAWs, and presented as an alternative to existing techniques for measuring and compensating round-trip latency. Furthermore, the proposed method has been integrated and is accessible in a real-world application through the open-source platform Hi-Audio. An experimental phase based on this solution was conducted using various devices and operating systems, to validate the results in the absence of prior references in the literature. The findings clearly demonstrate the heterogeneity of the browser ecosystem and the wide variability of measured values. Two distinct experiments were performed using the MLS signal to: (1) identify the browser offering the most stable latency calculation—Firefox in this case—and (2) compare the available methods on similar digital platforms and their behavior when using an MLS signal as input and applying proper calibration. Certain limitations were observed, particularly the presence of adaptive filters for echo cancellation or noise reduction, highlighting the necessity of controlling audio constraints not only at the browser level but also within the operating system. The proposed approach has been extensively evaluated under a wide range of recording conditions, including acoustically challenging and high-noise environments such as conference venues. Tests were conducted using various hardware configurations—such as built-in microphones and loudspeakers, line-in instruments with external sound cards or Bluetooth headsets. Overall, the method demonstrated strong robustness and efficiency under lower input gain values, compared to conventional techniques relying on impulsive noise or sinusoidal beeps test signals, but still some challenges remain to overcome the heterogeneity of hardware platforms, web browsers, and the underlying audio processing technologies, which hinders the consistency of performance across settings. 6. ACKNOWLEDGMENTS This work was funded by the European Union (ERC, HiAudio, 101052978). Views and opinions expressed are however those of the author(s) only and do not necessarily reflect those of the European Union or the European Research Council. Neither the European Union nor the granting authority can be held responsible for them. Special thanks to Louis Bahrman for his support in developing the Python utility used for computing the correlation. 7. REFERENCES [1] Michel Buffa and Antoine Vidal-Mazuy. Wam-studio, a digital audio workstation (daw) for the web. In Companion Proceedings of the ACM Web Conference 2023, pages 543–548, 2023. [2] Ulf Hammarqvist. Audio latency in browser-based daws. www.w3.org/2021/03/media-production-workshop/ talks/ulf-hammarqvist-audio-latency.html. Accessed: 2025-06-08. [3] Android. Audio latency measurements. https://source. android.com/docs/core/audio/latency/measurements. Accessed: 2025-06-08. [4] W3C. Web audio api spec. https://www.w3.org/TR/ webaudio-1.1/#ScriptProcessorNode. Accessed: 2025-06-08. [5] Michel Buffa. Walatencycompensation. https: //github.com/micbuffa/WAlatencyCompensation. Accessed: 2025-06-08. [6] Mozilla. Audiocontext: outputlatency property. https://developer.mozilla.org/en-US/docs/Web/API/ AudioContext/outputLatency. Accessed: 2025-06-08. [7] Harvey Dillon, Gitte Keidser, Anna O’Brien, and Heidi Silberstein. Sound quality comparisons of advanced hearing aids. The hearing journal, 56(4):30–32, 2003. [8] Yonghao Wang, Ryan Stables, and Joshua Reiss. Audio latency measurement for desktop operating systems with onboard soundcards. In 128th Convention of Audio Engineering Society, London, 2010. [9] Paul Adenot. Audio roundtrip latency measurements. https://github.com/padenot/roundtrip-latency-tester. Accessed: 2025-06-08. [10] Gabor Szanto. Web browser audio latency test. https://github.com/superpoweredSDK/ WebBrowserAudioLatencyMeasurement. Accessed: 2025-06-08. [11] Jos´e Manuel Gil Panal, Aur´elien David, and Gael Richard. Hi-audio online platform: Opportunities and challenges of collecting varied music data on the web. In International Society for Music Information Retrieval Conference (ISMIR), Late-Breaking Demo, 2024. [12] D.V. Sarwate and M.B. Pursley. Crosscorrelation properties of pseudorandom and related sequences. Proceedings of the IEEE, 68(5):593–619, 1980. [13] M.G. Schroeder. Integrated-impulse method measuring sound decay without using impulses. Journal of the Acoustical Society of America, 66:497–500, 1979. [14] Paul Adenot. Web audio api performance. https://padenot.github.io/web-audio-perf/ #browser-architecture. Accessed: 2025-09-22. [15] W3C. Mediatrackconstraints. https://w3c.github.io/ mediacapture-main/#dom-mediatrackconstraints. Accessed: 2025-06-08. [16] Mozilla. Mediatrackconstraints: channelcount property. https://developer.mozilla.org/en-US/docs/ Web/API/MediaTrackConstraints/channelCount. Accessed: 2025-06-08. [17] W3C. Media capture and streams. https://www.w3. org/TR/mediacapture-streams/#dfn-latency. Accessed: 2025-06-08. [18] W3C. Web audio api spec. https://webaudio.github.io/web-audio-api/ #dom-audiocontextoptions-latencyhint. Accessed: 2025-06-08. [19] JVC Paulo, CR Martins, JL Coelho, and Av Eng Bonneville Franco. On the use of the mp3 format and m sequences applied to acoustic measurement. Appendix: Additional results using Firefox Table 2: Table showing the round-trip latency values obtained during Phase 2 in different online DAWs using Firefox. Device / DAW app MLS latency no comp. (ms) Latency estimation (ms) MLS latency with comp. HP Ubuntu 22.04 Soundtrap1-175.46 249 -182.77 Amped Studio238.05 69 -11.38 Bandlab 65.12 139 -73.85 WAM-online studio396.96 79.14 58.66 Hi-Audio 66.64 66.39 0.68 Lenovo Windows10 Soundtrap1-90.79 314 -179.08 Amped Studio255.77 146 -7.96 Bandlab4,5131.42 147 -14.56 WAM-online studio3,5149.12 129.71 53.73 Hi-Audio 138.50 138.44 0.48 MacBook Pro 2021 Soundtrap1-184 232 -194.24 Amped Studio6- - - Bandlab 38.71 38 0.73 WAM-online studio348.73 36.37 20.66 Hi-Audio 39.07 38.96 1.09 1Soundtrap applies a default compensation before running the actual latency test. 2Amped Studio shows in Settings options a default value of 20 ms for latency compensation in Ubuntu and macOS, and 80 ms for Windows. 3WAM-online studio measures the round-trip but to compensate it applies a lower value by subtracting the output latency to the round-trip. 4Bandlab applies a preprocessing of the signal, similar to web audio constraints. 5The output volume needs to be increased from 66 to 87 to properly run the latency test. 6Recording from mic not working for Firefox in macOS.