W3C home > Mailing lists > Public > public-media-capture@w3.org > May 2015

Re: Specifying the audio buffer size

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 12 May 2015 22:48:05 +0200
Message-ID: <55526705.6040802@alvestrand.no>
To: Jan-Ivar Bruaroey <jib@mozilla.com>, Charlie Kehoe <ckehoe@google.com>, Justin Uberti <juberti@google.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
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.
Received on Tuesday, 12 May 2015 20:48:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:33 UTC