W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2013

Re: TAG feedback on Web Audio

From: Jer Noble <jer.noble@apple.com>
Date: Wed, 07 Aug 2013 09:24:14 -0700
Cc: Srikumar Karaikudi Subramanian <srikumarks@gmail.com>, Chris Wilson <cwilso@google.com>, Marcus Geelnard <mage@opera.com>, Alex Russell <slightlyoff@google.com>, Noah Mendelsohn <nrm@arcanedomain.com>, Anne van Kesteren <annevk@annevk.nl>, Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>, "robert@ocallahan.org" <robert@ocallahan.org>, "public-audio@w3.org" <public-audio@w3.org>, www-tag@w3.org, List <www-tag@w3.org>
Message-id: <54D6C57E-EB5A-4315-818B-5EEC8E34BA99@apple.com>
To: "K. Gadd" <kg@luminance.org>

On Aug 6, 2013, at 6:56 PM, K. Gadd <kg@luminance.org> wrote:

> Given flash's continued prevalence for streaming realtime audio/video and use cases like video chat and game rendering, whatever works for the pepper flash plugin should probably work okay for web audio (though it certainly isn't necessarily *needed*).

I believe this is a faulty premise.

Video, especially 24 FPS video, is much more immune to jitter and delays than is audio.  In the video case, frames are 30 to 40 ms apart, and if a frame is delayed by a few ms, that delay is almost imperceptible to the human eye.

With 44,100 kHz audio and a small frame size (128 samples in Blink & WebKit Web Audio, usually), each batch of samples is only 3 ms apart, and if those samples are delayed even by less than a millisecond, there will be an audible ‘pop’ in the rendered audio.

Additionally, I would assume that in Chrome the video is piped back to the main process for rendering, but the audio is rendered locally in the plugin process.

Received on Wednesday, 7 August 2013 16:24:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:23 UTC