Re: Specifying the audio buffer size

Note from the Audio WG side: MediaStreams can be bridged into an
AudioContext that has a different sampling rate from the device. So from a
developer point of view, latency in seconds seems less error-prone than one
expressed as a buffer size.

...Joe

On Thu, May 14, 2015 at 8:42 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

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


-- 
.            .       .    .  . ...Joe

*Joe Berkovitz*
President

*Noteflight LLC*
49R Day Street / Somerville, MA 02144 / USA
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"