Re: Integer PCM sample formats to Web Audio API?

2014/1/9 Marcus Geelnard <mage@opera.com>

>  Hi again,
>
> I'm definitely not saying "WONTFIX". Just to be clear, I fully support the
> idea of adding support for creating AudioBuffers from integer sample
> formats.
>
> I might have misunderstood your message. When reading about "triple-A
> games" and "games engine middleware" I started thinking about contemporary
> products, and figured that the best solution would be to use a proper Web
> Audio API back end for such situations, rather than an
> OpenAL/SDL_audio/whatever-on-top-of-WebAudio wrapper.
>

Right. However the problem is that even if I had the ability to rewrite
instead of just 'naively port', there is no 'proper Web Audio API back end'
way for solving this problem. Even if I write my application fully in
native Javascript ground up, I can still not use a 16-bit integer format to
save memory. For this particular issue, I think linking to the SDL library
carried the discussion away a bit.

If there was an added AudioBuffer-from-int16 array form and the conversion
to float was done under the hood on demand if needed, I would hope the
following features to go along with it:
  - Explicit performance guarantees in the spec for which function calls
and situations will cause an expansion of the int16 array to float32.
  - 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.
  - 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.
  - A function call that allows extracting the AudioBuffer data back as an
int16 array.

Weak unspecified performance guarantees with "you'll get the fast path if
stars align" are a sign of a badly designed API (looking at you OpenGL). I
understand if compromises may need to be made in the case when the initial
design was already done and only later it was realized that new features
needed to be added in. In this case, I'd be willing to accept if
strongly-typed AudioBuffers were too difficult to spec in anymore and that
a conversion/lifting could happen on-demand if needed, but I'm not willing
to accept a minimal "use this one newly added function call, and cross your
hands to hope that you will get what you want" patchwork. I don't want to
see a case where everything seems to initially work, and then three months
after you add a seemingly unrelated functionality that does something
"processing-like" (dynamically adjusting volume by distance to audio
receiver, add 3D positional audio source support, etc.) and after that
newly added call you _silently_ start having float32 buffers everywhere,
but only on that certain OS and that certain browser with that single audio
card that nobody else has.

The feature needs to be well-defined enough that it's actually debuggable.
It can't be an "all bets are off" type of thing, but there needs to be a
way to confirm that you are getting what you expect, or if you cannot get
what you expect, you need to be able to have a way to be explicitly aware
of the case. Silent failure is not an option.

Should I go ahead and add a bug about adding int16 support to
https://github.com/WebAudio/web-audio-api/issues ? I understand that is the
tracker used for spec bugs and feature requests?

   Jukka