Re: Is Web Audio a realtime API?

Hi Oleg,

Here is where I believe things stand:

- The Web Audio API does support what you are calling "real-time use” when the underlying OS allows this, and future spec versions will emphasize the need to minimize latency. Also there is a use case document that makes it clear that gaming and fast interaction are central concerns.

- At the moment we’re not currently requiring specific guarantees (e.g. minimum latency in milliseconds) for conforming implementations. Other web specs for graphics, etc. do not do this either, although there is a clear understanding that real-time performance is important.

- Some OSs have latency issues that are not possible to resolve in the web browser. So, as you said, Issue #12 captures the need to discover the implementation’s latency, which the WG has agreed is necessary.

Best,

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"


> 
> Thanks everyone for your feedback. Let me clarify what I actually meant by real time. My understanding of RT is totally in-line with definition on wikipedia http://en.wikipedia.org/wiki/Real-time_computing. That can be shortened to one line that "Real-time programs must guarantee response within strict time constraints". I am mostly concerned about getting audio response within given deadline from games or interactive pages that rely on the web audio api. Here is an example where delay is noticeable on e.g. Android version of Chrome browser running on my Samsung Galaxy S4 device: http://webaudioapi.com/samples/rapid-sounds/.
> Actually, problem is well defined in the section "Performance Considerations - Latency" of the specification. So I am wondering if there is any intention to enforce performance constrains or provide developers with the API to check latency of the implementation. I believe that discussion at https://github.com/WebAudio/web-audio-api/issues/12 is something that I am very interested to read next then.
> 
> -Oleg
> 
> 

Received on Thursday, 15 January 2015 17:06:14 UTC