Re: Sites using webkitAudioContext only

On Thu, Jul 4, 2013 at 12:45 PM, Kevin Gadd <kevin.gadd@gmail.com> wrote:

> AudioElement#decode is a very interesting proposal. As much as I like it
> in theory I suspect it would probably be worse than the current state of
> things. In particular, it would eliminate the ability to load audio
> directly from a byte array - you'd have to turn it into an Object URL so
> that the audio element can use it as a src, then call decode on the
> AudioElement. On the other hand, that does nicely fit into a model where
> you can gracefully degrade to raw HTML5 <audio> in browsers where Web Audio
> is not available (JSIL does this at present).
>

Well I would actually prefer it that way, since currently the pain is on
the most common use case where you have to download the assets first.


> I agree with the points about AudioContext#destination and
> AudioContext#listener but I'm not sure those suggested changes really
> provide enough improvement to justify the work involved (or the changes to
> existing applications). The listener model in particular, while very
> limiting and arbitrary, is probably not causing most users any issues, so
> it's not as urgent to change it.
>
> -kg
>
>
> On Thu, Jul 4, 2013 at 2:32 AM, Jussi Kalliokoski <
> jussi.kalliokoski@gmail.com> wrote:
>
>> Oops, we accidentally went offlist with Roc:
>>
>> ---------- Forwarded message ----------
>> From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
>> Date: Wed, Jul 3, 2013 at 7:44 PM
>> Subject: Re: Sites using webkitAudioContext only
>> To: Robert O'Callahan <robert@ocallahan.org>
>>
>>
>>  I liked your Media Streams Processing API proposal, but obviously we
>> won't be going back to that, so my idea of corrections we need to make is
>> at least these:
>>
>> AudioContext#createBuffer():
>>  * new AudioBuffer(sequence<Float32Array> data, sampleRate). This will
>> avoid the synchronous memory allocation so authors can even offload the
>> creation of the actual buffers to Web Workers. It also helps avoid an extra
>> copy if you already have the data when you create the buffer.
>>
>> AudioContext#decodeAudioData():
>>  * At the very least this should return a promise instead of the
>> callbacks as arguments.
>>  * Is there some way we could integrate this into AudioElement? e.g.
>> Promise AudioElement#decode(). This would make the normal pipeline of
>> loading the assets simpler as well.
>>
>> AudioNodes:
>>  * Use constructors.
>>
>> AudioContext#destination
>>  * Use AudioElement here as well? Either assign a MediaStream as the
>> `src` or even better, make AudioElement and MediaStream connectable to,
>> e.g. myGainNode.connect(myAudioElement) and there we have all that's
>> required to make an audio stream audible. The AudioElement would work as
>> the sink here so if for example pause() is fired, it would stop pulling in
>> content. (That would fix the much wanted pause requirement as well)
>>
>> AudioContext#listener
>>  * First of all I don't think spatialization should be part of the first
>> release, but aside from that:
>>  * Each spatialization node has its own listener, or
>>  * AudioElement and MediaStream have a listener associated to them
>>
>> AudioContext#createPeriodicWave()
>>  * Use a constructor.
>>
>> Cheers,
>> Jussi
>>
>>
>> On Wed, Jul 3, 2013 at 11:04 AM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Wed, Jul 3, 2013 at 7:39 PM, Jussi Kalliokoski <
>>> jussi.kalliokoski@gmail.com> wrote:
>>>
>>>> 1. Web Audio API is not webby: I agree, and have been ranting about
>>>> this enough already. Let's fix this.
>>>>
>>>
>>> Do you have any particular proposals in mind?
>>>
>>> Rob
>>> --
>>> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny
>>> eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha
>>> iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e
>>> tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea
>>> lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w  *
>>> *
>>>
>>
>>
>>
>