Re: Specifying the audio buffer size

On 5/11/15 6:22 AM, Harald Alvestrand wrote:
> Den 05. mai 2015 00:00, skrev Charlie Kehoe:
>> Any additional thoughts here? The May 15th deadline is not too far away.
> My feeling based on the discussion is that "buffer size" is still the
> wrong number, because it doesn't describe what the user's constraint is.
> "maxMediaDelay" may be more appropriate - "I can tolerate this many
> milliseconds of delay with no impairment to my service" might be a good
> description of semantics.

Agree about buffer size.

Bike-shed: I like the word "latency" (" the delay between the receipt of 
a stimulus and the response to it") even better than "delay", as it 
sounds like a quality metric that tracks with power cost. I.e. the point 
is not to delay, but to choose a service with a lower/higher (latency, 
and, inversely, power) rating.

"Media" seems superfluous for media constraints.

Unit prefixes (e.g. *Ms) is uncommon with constraints. E.g. width not 
widthPx

I don't seem milliseconds much in our APIs. E.g. for jitter in 
RTCInboundRTPStreamStats we use seconds in a double. Perhaps because we 
don't use unit-prefixes, perhaps because it lets us express 2.5 ms.

> For systems that deliver low latency in their only available code path,
> they would continue to deliver low latency.
>
> At the other extreme, apps that want low latency could request that
> (using ideal) or require that (using max), and get appropriate behavior.

IMHO we should avoid the word "max" in a constraint to avoid confusion 
with constraint min and max values. E.g.

   { maxLatency: { max: 0.250} } // max max?
   { maxLatency: { min: 0.250 } } // min max?

I think ideal can work symmetrically here (plain values are ideal):

   { latency: 0.0025 } // prefer low-latency
   { latency: 0.025 }  // prefer high-latency

And users should be allowed to make calls fail either way IMHO:

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

.: Jan-Ivar :.

> One good question is what part of the system we measure delay across,
> though.