Re: Is Web Audio a realtime API?

On 01/15/2015 12:55 PM, Paul Adenot wrote:
> On Wed, Jan 14, 2015 at 7:52 PM, Raymond Toy <rtoy@google.com 
> <mailto:rtoy@google.com>> wrote:
>
>
>
>     On Wed, Jan 14, 2015 at 9:02 AM, Chris Lilley <chris@w3.org
>     <mailto:chris@w3.org>> wrote:
>
>         Hello Oleg,
>
>         Wednesday, January 14, 2015, 3:11:56 PM, you wrote:
>
>         > Specification lists performance and latency considerations, but
>         > does not explicitly state if API is realtime or not.
>
>         That depends on your definition of realtime.
>
>         On the one hand, it concerns audio which is generated "in
>         realtime"
>         rather than previously recorded audio which is merely played back.
>
>         On the other hand, it will almost always be executed on a
>         non-realtime, multitasking OS rather than a RTOS. And audio
>         samples
>         are processed in blocks rather than as individual samples, so
>         sample-accurate sync is hard (128 samples at 44.1k is 2.9ms).
>
>
>     I believe the api does give you sample-accurate sync, even if the
>     samples are processed in blocks.
>
>
> Yes, in the sense that you can *schedule* sound to be started at a 
> specific sample, in the future (maybe 10ms or so).
>
> Implementations as of today try to reach the lowest audio output 
> latency available on a consumer system (no ASIO/other specialized API, 
> no exclusive access, although I seem to recall seeing some code about 
> that in the Chromium tree).
>
> Implementation also try to use higher-priority thread where possible 
> (OSX, Windows/WASAPI, PulseAudio and Android, both OpenSL and regular 
> AudioTrack, are platforms where you can have access to a higher 
> priority threads.
>
> We have discussed having an API to get the latency, to be able to have 
> very precise audio/video synchronization (for games and other 
> interactive media, as you mention). You can follow along and jump in 
> the discussion at [0].

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