There should be a programatic way to determine hardware/input latency
Reported by
iamcraig...@gmail.com,
Apr 12 2017
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Steps to reproduce the problem: I am working on building a fairly complex web audio application and one thing I have been struggling with is figuring out how to line up audio recorded using navigator.getUserMedia() with existing audio on the Web Audio API graph. In Chrome Canary there is an AudioContext.baseLatency property, but it is my understanding that that is just the latency added internally by the web audio API itself. When using getUserMedia() and hooking it up to a ScriptProcessorNode you can capture the input audio signal. What I have found is even after subtracting the latency from the onaudioprocess callback itself (bufferLength / sampleRate), the captured audio still does not line up perfectly with existing audio in the web audio API graph. I have played around with various latency amounts, and I can get it to match up if I subtract another 20-30 ms or so, but that amount would be specific to my OS/audio hardware setup. Is there any way to programmatically determine the latency of the audio input from getUserMedia/hardware/drivers? I found this Stack Overflow question from a few years ago, and I am not sure if it is still relevant: http://stackoverflow.com/questions/21428511/playing-and-recording-with-a-constant-latency-on-browser-with-javascript-usermed Any help/insight would be greatly appreciated. What is the expected behavior? It would be nice to figure out the latency amounts programmatically What went wrong? There is no way to do this (that I could find) Did this work before? N/A Does this work in other browsers? N/A Chrome version: 57.0.2987.133 Channel: stable OS Version: OS X 10.12.4 Flash Version: Writing a reproduce case is possible, but will take me quite a lot of time cause of all of the components involved.
,
Apr 12 2017
,
Apr 12 2017
+dalecurtis Do you know what the input latency is?
,
Apr 12 2017
I'm guessing this is the time at which audio is received from the microphone relative to when the application processes it. See https://codereview.chromium.org/2689483006 where I've started trying to plumb this concept (though lack the actual values).
,
Apr 14 2017
@dalecurtis curious if you could provide any additional insight that may be able to help me. If there is no way to programmatically determine this as of right now, what would be your recommendation for how to line up captured audio with a web audio API graph? Would something like Chris Wilson mentioned on the Stack Overflow (using stored figures for average IO latency per platform) be the best option? I don’t really want to have to make users “calibrate” their audio input so to speak in order to use the application. Is the latency built into the way Chrome processes the audio or does it also depend on the audio interface being used? Using the built in microphone on my MacBook Pro I have figured out that if I subtract approximately 30-40 ms it seems to line up just about right, but is it a safe assumption that everyone using Chrome on OS X will have the same experiende? I don’t have access to a lot of hardware to test on. Thanks
,
Apr 25 2017
as per dale in c#3, this issue already addressed. give to dale to follow up with bug opener or close this bug. it is related to crbug/609890
,
Apr 25 2017
The latency is likely an artifact of the OS level capture process as we deliver it directly into JavaScript I believe. Probably OSX is giving us this timing information but we are not delivering it to the application at present. I don't think there's a way to do this currently. We used to have support for a similar type use case but no one used it and it was a massive support burden; i.e a WebAudio application could process input and provide output within the same cycle.
,
Apr 27 2017
Marking as available. I think we should route this information to clients, but we first need to route it at all.
,
Apr 27 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 27 2018
stale bug no action for > 1 year. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ajha@chromium.org
, Apr 12 2017