W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2015

Re: Initial draft of mediacapture-output spec posted

From: Chris Wilson <cwilso@google.com>
Date: Mon, 5 Jan 2015 09:23:04 -0800
Message-ID: <CAJK2wqUdZ7s2jAs_gSrEUO=dT_U1dWUAx4Nz_qhW5fOqXX5=2Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Justin Uberti <juberti@google.com>, Philippe Joseph Cohen <philc@audyx.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
I'm merely looking at this from a scenario perspective, and there's a lot
that I presume is implied in the spec but I don't understand how it would
work in practice.  It's all very well to say " media device information
depends on whether or not permission has been granted to the page's origin
to use media devices," but the scenario (and exposure) of enumerating all
output devices to see if you have a "good enough" device, for example, is a
bit different than asking for access to audio input streams.

I'm not intending to blow up any model; just trying to ensure we have a
model that we can use, in the end, to replicate the default behavior - e.g.
to demonstrate how one would implement <audio> on top of the Web Audio API
and the Web Audio API on top of some underlying basic stream-like API.

On Tue, Dec 23, 2014 at 9:50 AM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 23 December 2014 at 08:19, Chris Wilson <cwilso@google.com> wrote:
> > A use case for supported sample rates/bit depths?  Well, any decent
> digital
> > audio workstation (and even non-decent DAWs) enable the user to select
> the
> > appropriate bit rate for a connected device, to get the best quality
> (i.e.
> > not being multiple-resampled).  Even just for the use case of trying to
> hook
> > into the default audio device appropriately, we need to understand its
> basic
> > capabilities.
> >
>
> I wasn't looking for you to try to convince *me*, I was merely
> expressing what I saw as the constraints.  I personally have no
> objection to surfacing more useful information, particularly if you
> are willing to contribute work, but there may be others who are
> concerned about any potential to delay the existing work.
>
> > Realistically, the fingerprinting surface area here is relatively
> minimal -
> > and just not talking about it in the spec doesn't make it larger or
> smaller.
>
> That's not an argument that holds water.  If you look at the spec [1],
> you can see how we've dealt with this thus far.  It's probably not a
> bad idea to follow that model unless you want to blow things up.
>
> [1] https://w3c.github.io/mediacapture-main/#access-control-model
>
Received on Monday, 5 January 2015 17:23:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:50 UTC