W3C home > Mailing lists > Public > public-coremob@w3.org > October 2012

Re: Realistic web app expectations for mobile Audio?

From: Tobie Langel <tobie@fb.com>
Date: Mon, 15 Oct 2012 12:33:25 +0000
To: Christopher Cook <christopher.cook@webprofusion.com>, "public-coremob@w3.org" <public-coremob@w3.org>
Message-ID: <F9981AFB970564408FEB7DFCF62D44084367B1E7@SC-MBX01-4.TheFacebook.com>
Hi Christopher,

On 10/12/12 10:26 PM, "Christopher Cook"
<christopher.cook@webprofusion.com> wrote:

>Hi Folks,
>Regarding the Audio part of the mobile web experience I see we're trying
>to get low-latency multi-channel playback - I'm assuming that's for
>audio which has been fully loaded and is ready to play.

That's correct.

>The 10ms latency 
>target sounds great but may be quite tricky to test for?

Absolutely. Absence of artifacts in play back is also going to be a tricky
one to test.

I'm not expecting we can test all of these.

>Are there any ambitions for recording support to be part of the core

Well, currently only through the HTML Media Capture api, so that wouldn't
cover your use case below (it's not live input streaming).

>My specific example is a guitar tuner feature within a guitar
>related app but there are plenty of other scenarios. In a best case I
>would like musicians to be able to collaborate with each other via their
>phones 'live' (network permitting). I imagine it's only realistic to
>hope for 2 mono channels or one stereo input at best.

Those use cases are definitely interesting ones for future work.

>I realise the Web Audio API is broadly referenced here

It's not. We focused our attention on the AUDIO element of HTML5 only so
far, although an issue was raised for us to reconsider more advanced APIs
now that they've reached broader consensus (apparently).

>but regarding 
>minimum supported features, latency in both playback and especially
>recording is likely to be unpredictable due to OS and hardware

You're touching on an important issue here. What are we testing for
conformance: the browser, or the combination between the browser and the
device it's hosted on.

>I'm not aware if the API allows for these latencies to be
>detected and compensated for?

I guess you're referring to latency compensation when overdubbing. This is
totally out of scope of our current work.

The only latency we're looking into atm is the lapse between when
application level code triggers a pre-loaded sound and that when that
sound is effectively played by the device's sound card.

>I am aware that the current support on
>desktops for the Audio API is still yet to reach maturity and on mobile
>I'm lucky if anything works yet. Perhaps this API does not yet have the
>required test suite to determine correct functionality on any platform?

That's probable and something we'll need to determine if we consider this
API for inclusion again.

>Regarding the minimal audio latency figures, I found these guidelines
>for Adobe Audition quite succinct:

Thanks for this link. This is useful.

Received on Monday, 15 October 2012 12:33:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:48 UTC