Closed cwilso closed 8 years ago
Is it going to be the same even for all WebRTC-related MediaStream
s? It's not obvious to me that the audio from a local microphone and that coming from a remote RTCPeerConnection
would have the same "pass through" latency.
Change processingLatency to baseLatency to avoid confusion. Otherwise accept revision to add numeric value.
Note: this constructor option and the latency property are only valid for real-time audio context.
/sub The latency constraint (a request to getUserMedia) is already in that spec.
Question. If the user specified "interactive" (or some other enum), what should baseLatency
return? Should it be the actual latency or "interactive"? As currently spec'ed in #775, we need to return a double, but should it also support enums? A double is nice, though.
Finally, it's the time in sec. A value in msec would be more natural, but does make it different from all other time values in WebAudio.
Having baseLatency
always be a double would make sense to me. Otherwise there's presumably no way of knowing what "interactive" mapped to, and if knowing baseLatency
is ever useful it ought to be potentially useful in that case as well.
Agree that double would be useful even if it's best effort.
On Thu, Apr 14, 2016, 11:21 Philip Jägenstedt notifications@github.com wrote:
Having baseLatency always be a double would make sense to me. Otherwise there's presumably no way of knowing what "interactive" mapped to, and if knowing baseLatency is ever useful it ought to be potentially useful in that case as well.
— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/WebAudio/web-audio-api/issues/348#issuecomment-209844241
I actually like a numeric value for all cases too. I'm going to leave it as double, then.
It's been requested that we enable a batching mechanism to let users of the API tell us to process a batch of frames at a time (rather than the lowest latency we can support on a given system), trading off higher latency for applications that would rather minimize power (e.g. a simple background-music-playback app).