"Implementing <audio> on top of..." (Re: Initial draft of mediacapture-output spec posted)

On 01/05/2015 06:23 PM, Chris Wilson wrote:
> 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.

Sorry, you lost me totally here.

Why would we want to demonstrate those things?

And - given my oft-repeated observation that a MediaStream is very far
from being "stream-like" - does it even make sense to try, given that
there is no commonality of underlying concepts?


>
> On Tue, Dec 23, 2014 at 9:50 AM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 23 December 2014 at 08:19, Chris Wilson <cwilso@google.com
>     <mailto: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
>
>


-- 
Surveillance is pervasive. Go Dark.