Is the audio latency value in MediaStream API according to spec?

[Ulf Hammarqvist]

Greetings!

Quick background - use case is building a DAW scale audio recording experience with latency compensation. This benefits from accurate full path latency figures which we hope to get from MediaTrackSettings.latency and AudioContext.outputLatency

The spec for input latency https://www.w3.org/TR/mediacapture-streams/#def-constraint-latency does seem to be the full path, which is what we are after.

```
The latency or latency range, in seconds. The latency is the time between start of processing (for instance, when sound occurs in the real world) to the data being available to the next step in the process. Low latency is critical for some applications; high latency may be acceptable for other applications because it helps with power constraints. The number is expected to be the target latency of the configuration; the actual latency may show some variation from that.
```

However, looking at this using a fiddle
https://jsfiddle.net/2oafnkbh/1/
the latency numbers are close to what looks like an internal buffer size. 

on max osx, chromium, we see
latency*samplerRate ~= 128
regardless of sampleRate

whereas we'd expect something like 128+X where X is the additional latency imposed by the internal buffering/system/hardware etc.

(tangentially, this was mentioned on a w3c workshop on media production, see https://github.com/w3c/media-production-workshop/issues/31)

regards, Ulf

[mark a. foltz]

+media-ca...@chromium.org as this looks like a getUserMedia() related question.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/a612899e-475f-44da-ab99-5ba982fd3353n%40chromium.org.

[Ulf Hammarqvist]

To clarify our perspective (and the one we brought up on the w3c workshop) is that for the (music production) audio recording use case, we need as accurate latency figures as possible so we can align the recorded data to some timeline.

On Wed, Mar 9, 2022 at 11:29 AM Tony Herre <he...@google.com> wrote:

+h...@chromium.org 

It is indeed the size of a single buffer, set here. I guess when one is thinking of the constraint side here, where a web app is specifying what it wants when opening the microphone, then controlling the size of this buffer is more or less what we want to allow for tuning e2e latency vs efficiency.

GetSettings() seems to be implemented mostly as a "what settings actually got applied to this track" rather than a monitoring interface, as far as I can tell, so in the case where the constraint is not set in the getUserMedia() call, it just returns the default buffer size. I'm not sure how close this is to the spec intentions. Harald, what should the semantics be in your opinion?

You received this message because you are subscribed to the Google Groups "media-capture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to media-capture-...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/media-capture-dev/CALgg%2BHFjydDU3ez61haRK%2B5bAXN6B5M2WXyKMEeS_3FwsHXSdQ%40mail.gmail.com.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.