New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Latency measurement and low-latency #31
Comments
I also wonder if any browsers plan to support e.g. ASIO on Windows and Jack or ALSA directly on Linux, which are technologies that works well for desktop apps to provide low latency. Is this something that even could be considered for web api specs? The possibility for a web app to choose using ASIO, Jack, ALSA etc. |
This one is important. For example, in Firefox, This scheme is to optimize for the (overwhelmingly common) case where there is a single audio input device and a single audio output device, and allows having super low latency and high performance with no change of drifting. Also, when running Finally, when an All in all, this means that the latency of a In Firefox, that implements
Indeed, if the device id is passed in at the creation of the |
The ASIO SDK is proprietary, so open-source browsers can't easily ship something with it (last I checked). JACK and ALSA can be used in Firefox today, but are not as well maintained as the Pulse backend, they do however receive community support and we review and ship fixes to those audio backends. I hear the JACK backend should work on other OSes, and this could be a bridge to ASIO on Windows. I haven't tried this myself.
This seems a bit advanced and specific. An implementation could try to find a Jack server an ASIO driver, and device to use this if, e.g. and |
I think it would be good to be able to list available audio devices/drivers in the API and so make it possible to choose it from a web-app. For pro music / media production you may want to control which driver / device to use, and not have it automatically decided based on latency hint. E.g. in JavaSound you have this possibility (I was working with a DAW implemented in Java earlier), and just as the midi API lets you choose midi device it would be great to be able to choose the audio device/driver. |
This of course excellent, but what about the input device and input latency? I do notice #32. The roundtrip (input+output) latency is important for audio recording tasks. @padenot Some further thoughts on input latency (in the webaudio perspecive); How about if we could query / subscribe the node for latency changes up until that point (in WebAudio's clock domain)? |
Input is slightly different in the sense that if a device become unavailable, the
There's been some talk about having a latency parameter on I any case something needs to happen for sure, we need to find the most useful way to expose those numbers. |
as briefly discussed on the w3c session 1, what about the detectability of accuracy of these latency figures? (a mouthfull) |
I haven't been able to programmatically detect that this is the case short of feeding an output device back into an input device in a controlled environnment, in the general case, I'd be happy to know that this is feasible. On some of my machines it's very clear, just by ear, that the numbers reported by the OS is wrong. Most often the case for input iirc. |
If the OS/drivers is lying, or lacking the APIs to probe, that's of course a problem. Thinking freely here, but is there any way to shift the industry to implementing these types of apis correctly? I acknowledge it's very hard... Other than that, just checking in to see if there's been any progress towards implementing the specs? |
I know that Chromium has made a lot of progress in output latency reporting, I think the APIs are implemented now and are shipping in 102. |
Inconsistent latency across browsers/OS, both generally speaking as well as when the computer is running on battery power. And latency is not exposed everywhere.
Features in specs but not implemented across all browsers:
MediaStreamTrackSetting
)WebAudio
)Possible spec gaps:
MediaStreamSourceNode
- adds latency?Ongoing work in the Audio Working Group to create a new API that allows apps to select the audio output device for an audio context. Theoretically, this will guarantee the code path that minimizes the output latency.
Raised in:
The text was updated successfully, but these errors were encountered: