W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Round Trip Latency test

From: Joseph Berkovitz <joe@noteflight.com>
Date: Thu, 4 Sep 2014 11:11:29 -0400
Cc: Alex Russell <slightlyoff@google.com>, Stephen Band <stephband@cruncher.ch>, "public-audio@w3.org" <public-audio@w3.org>
Message-Id: <C46642EA-6A8A-4A7E-A4AF-A9459574EDEA@noteflight.com>
To: Chris Wilson <cwilso@google.com>
For what it’s worth, a contact in the pro audio software world assures me that two buffers’ worth of latency (= 256 samples at 44.1 = ~6 ms) is pretty much the standard for professional DAWs these days. There is always an assumption inside DAWs of the need to hop process boundaries: multithreading is a bigger win than further, imperceptible decreases in latency past two buffers’ worth.

This probably excludes any latency in the low level audio I/O pipeline — it’s just intra-DAW latency.

…Joe

On Sep 2, 2014, at 4:29 PM, Chris Wilson <cwilso@google.com> wrote:

> Hey Stephen,
> do you have an un-minimized version of your code?  I can't understand how you're accounting for the inherent ScriptProcessor latency.  I also didn't see a clear 2x drop when I doubled my sample rate, which I wanted to investigate.
> 
> The design of the Web Audio API was intended to provide low-latency in audio; realistically, <10ms is hard to do without an optimized audio path *and* a high sample rate.  (A single 128-sample block at 44.1kHz is just under 3ms.  If you're hopping process boundaries, and you usually are, you'll need to double-buffer.  That's 6ms.  The input has the same buffering - so you're up to 12ms.  And that's an idealized path...)  This is why even pro audio hardware frequently has a "direct pass-through"... :)
> 
> 
> 
> 
> On Sat, Aug 30, 2014 at 2:21 PM, Alex Russell <slightlyoff@google.com> wrote:
> On Sat, Aug 30, 2014 at 12:46 PM, Stephen Band <stephband@cruncher.ch> wrote:
> It's nothing to do with the UI really.
> 
> 
> I understand that this wasn't in any way a test of UI, but in terms of the goal of reducing latency, I'd have assumed that being able to match UI closely (in response to input, e.g.) would be a goal and impls are some distance of that (although we also have bad delay in touch inputs for various reasons that are boring).
> You're doing well if you get less than 40ms out of a standard sound card, but if you use a good external audio interface you could see as low as 5ms.
> 
> Above 15-20ms is when the ear starts to hear two distinct sounds, although it can be uncomfortable to sing and monitor with a latency of >10ms.
> 
> Thanks for the context. 
> So I would say a good latency would be <10ms. But good luck getting there :)
> 
> Looks like we're gonna need it = )
>  
> On 30 Aug 2014 21:21, "Alex Russell" <slightlyoff@google.com> wrote:
> What's a "good" number for this? I'm assuming less than a UI frame (16ms) is preferred? I'm seeing ~50ms on Chrome Dev/OS X/MBP and FF doesn't seem to detect all of the signals in my view.
> 
> 
> On Sat, Aug 30, 2014 at 11:24 AM, Stephen Band <stephband@cruncher.ch> wrote:
> In case someone should find it useful, here's a round-trip latency tester:
> 
> https://sound.io/latency/
> 
> 
> 
> 
> 



.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"
Received on Thursday, 4 September 2014 15:12:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC