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

This is all pertinent to my point.  I don't particularly care about
Streams, or MediaStreams, or whatever - if they're not the right
primitives, then let's fix that.  (For what it's worth, I think I currently
agree with you that MediaStreams aren't "stream-like" - at least, in
Domenic's current concept of Streams.)  But regardless, we need to build up
from the bedrock, and show our work in the successive layers from bedrock
APIs to higher level APIs like most of Web Audio.  Bedrock, in my
particular milieu of audio, requires an API to enumerate and examine the
capabilities of audio-capable devices and a way to pipe bits in and out.

On Tue, Jan 6, 2015 at 7:27 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 06. jan. 2015 16:03, skrev Anne van Kesteren:
> > On Tue, Jan 6, 2015 at 3:53 PM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
> >> (If one could design the primitives first, and build the other APIs on
> >> top of them, I think that the result may have a greater chance of being
> >> useful. But that's not what's being proposed.)
> >
> > In brief the problem with the web is that we started high and when we
> > went lower we did not look back to where we came from. Figuring out
> > where the mismatches are does seem useful so we can plug the holes and
> > make it all a bit more coherent, but it's not exactly trivial as
> > Domenic found out:
> >
> >   https://github.com/domenic/html-as-custom-elements
> >
> >
> "Not exactly trivial" is an understatement :-)
>
> For Chrome, the Blink-in-JS project seems aimed to do some of the same
> thing, but starting from a different angle.
>
> http://www.chromium.org/blink/blink-in-js
>
>