Re: Specifying the audio buffer size

Audio doesn't always go to the JS, so that seems like an unclear 
definition. Don't know about hardware variations.

Wouldn't it be easier to define latency strictly by the buffer size, 
since that's primarily what this setting would control? Seems to be 
where we started.

.: Jan-Ivar :.

On 5/13/15 5:57 PM, Charlie Kehoe wrote:
> I think "latency" is a good name to use. Sounds like it would be a 
> double specifying seconds.
>
> Ideally the actual latency measured would be from the time the 
> audio/video device receives the signal to the time the javascript sees 
> it. Individual implementations would probably have a minimum latency 
> below which they cannot operate, just like they support some bitrates 
> or video resolutions and not others.
>
>
> On Tue, May 12, 2015 at 1:48 PM Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     Den 11. mai 2015 22:28, skrev Jan-Ivar Bruaroey:
>     > On 5/11/15 3:41 PM, Harald Alvestrand wrote:
>     >> Den 11. mai 2015 17:08, skrev Jan-Ivar Bruaroey:
>     >>>    { latency: { max: 0.0025 } } // I wanna do something else
>     if not
>     >>> low-latency
>     >>>    { latency: { min: 0.025 } } // I wanna do something else if not
>     >>> high-latency
>     >>>
>     >>> Lastly, constraints are about abstracting access to shared
>     properties.
>     >>> Since this use-case is ultimately about power consumption, I
>     think it
>     >>> fits (e.g. I might want to know if another tab prevents me
>     from actually
>     >>> getting high-latency, so I can alter my apps's behavior).
>     >> This use case (speech recognition on mobile platforms) is about
>     power
>     >> consumption / latency tradeoff.
>     >>
>     >> The other use case I know of (interactive live music) is about
>     seeing if
>     >> delay can be controlled down to a tolerable level; power is almost
>     >> irrelevant in this context.
>     >
>     > Makes sense. Being a constraint (vs. say a UA property) shouldn't
>     > preclude a UA from in theory servicing such a request while
>     > simultaneously servicing higher-latency requests at the same
>     time, but
>     > it wouldn't require a UA to do so, which I think works.
>     >
>     > .: Jan-Ivar :.
>     >
>
>     Yes, that's where I was coming from when I inserted "max" in the
>     name -
>     I think we should always allow lower latencies than were asked for -
>     which contradicts the behavior of (say) width or height.
>
>     But it is consistent with (say) bandwidth constraints, so I have no
>     great beef about going with "latency" as the name of the constraint.
>