Re: Realistic web app expectations for mobile Audio?

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
>features?

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
>variation.

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:
>
>http://helpx.adobe.com/audition/kb/troubleshoot-recording-playback-monitor
>ing-audition.html#main_General_guidelines_that_apply_to_latency_times

Thanks for this link. This is useful.

--tobie

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