[whatwg] <device> element, streams and peer-to-peer connections

[Mark Frohnmayer]

On Sun, May 30, 2010 at 6:01 PM, James Salsman <jsalsman at gmail.com> wrote:
> It's hard for me to take http://www.w3.org/TR/capture-api/#formatdata
> seriously.  There are no references to open codecs or codec
> parameters; the only audio codec specified is audio/x-wav, which is a
> Microsoft-defined union type (RIFF) with a huge number of different
> possible instance types, including only a few poor quality open
> vocoders and audio codecs by contemporary performance/bandwidth
> standards.  Where is speex or ogg vorbis?  Where are their quality and
> bit rate parameters?  Why is http://www.w3.org/TR/capture-api/#future
> empty when most of the normative sections say, "No exceptions"?  Where
> is the compatibility with existing file transfer standards?  The
> security section doesn't contemplate permissions revocation.
>
> If audio were segmented into separate files as per
> http://www.w3.org/TR/capture-api/#captureaudiooptions how would that
> affect real-time performance on mobile devices?  Are these files
> required to have sequence numbers?  With phase vocoder time shifting,
> UDP delivery as per http://dev.w3.org/html5/html-device/#stream-api
> would be far superior in quality and intelligibility under packet loss
> or delay, assuming they went with an open audio codec (or, even
> better, allowed a choice of speex or ogg vorbis.)

To be clear I'm not advocating for one particular capture API or
codec; rather I'm advocating that capture and record not be tied to
network transport, and separately that the p2p network transport be
flexible, low-level, low-overhead and have a minimal attack surface
(suitable for real-time game data as well as audio/video).

Where is the discussion regarding phase vocoder time shifting and UDP
delivery?  I didn't see it in the stream-api section.

Cheers,
Mark