Re: Integer PCM sample formats to Web Audio API?

> >   - A way to query whether a given buffer is int16 or float32, to allow
> > code to assert() that it is getting what it desires. Otherwise debugging
> > can be a pain if the only way is for the programmer to measure this in
> > indirect ways via looking at memory consumption in a system process manager.
> 
> I would NOT want to do this.  This should be under the hood, and some
> systems (e.g. desktops with lots of memory) may choose to always expand.

I'd rather do something explicit, yes, but see below.

> >   - If the support for int16 is specced in to be optionally supportable (I
> > hope this will not be the case!), a way to ask the implementation if it
> > does support int16 format.
> >
> 
> I don't think you'd need this.  It's going to end up being a performance
> tradeoff - memory for CPU - that's likely better made by the platform
> implementation than the developer.  If we did want this, I'd expect this is
> a different decodeAudioData-style call.

I think that would address the use-case, here, while being retro-compatible.

We could pass in an optional value as last argument of decodeAudioData,
that would indicates that the author would rather save memory than have
a good quality / save some CPU.

It seems that it could be useful to specify sample rate and bit depth in
the decoded buffer, game developers have told us in the past that they
frequently use 22050Hz (or less) sounds in games, as well as 8/16 bits buffers.
Knowing their assets, only them can make the good call between cutting on the
sample rate, the bit depth, or both.

Then, the AudioBufferSourceNode (I think this is the main consumer, here) would
resample / convert to floating points lazily.

> >  - A function call that allows extracting the AudioBuffer data back as an
> > int16 array.
>
> Why? If we're going to do this, we would likely have to do other formats as
> well.
> 
> I'll be blunt - the Web Audio API is a floating-point API.  I understand
> the need to optimize by storing integer buffer data, particularly in
> constrained memory situations (and most of mobile falls in this category
> :), but I do not want to open the Pandora's box of trying to rework the API
> to be an integer-based API.

Agreed. It's preferable for the author to only deal with will float32
in content.

Cheers,
Paul.

Received on Thursday, 9 January 2014 19:50:01 UTC