Re: Round Trip Latency test

Indeed.  We should also provide better guidance to audio developers on the
usermedia options and echo cancellation.


On Thu, Sep 4, 2014 at 8:11 AM, Joseph Berkovitz <joe@noteflight.com> wrote:

> 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"
>
>