- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 12 May 2015 22:48:05 +0200
- 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