Re: Integer PCM sample formats to Web Audio API?

On Tue, Jan 14, 2014 at 1:28 PM, K. Gadd <kg@luminance.org> wrote:

> On Fri, Jan 10, 2014 at 12:53 AM, Marcus Geelnard <mage@opera.com> wrote:
>
>> I agree with Chris here. In general, an implementation has a much better
>> chance of making an informed performance trade off decision than a Web
>> developer. In most situations I think that int16 would save memory, but add
>> some extra CPU overhead. In other words, if a client has loads and loads of
>> memory, it could for instance decide to take the memory hit and convert to
>> Float32 internally in order to lower the CPU load, either up front or
>> lazily.
>>
>> If a Web page was to make the trade off decision, it would have to know a
>> lot more about the device it's running on (such as CPU performance,
>> available memory, etc), and since that is not the case, I fear that Web
>> devs would resort to things like UA sniffing etc to make distinctions such
>> as "desktop" vs "fast-tablet" vs "slow-phone", etc.
>
>
> We're not talking about web developers that know nothing about
> performance, though. This is specifically a use case where developers need
> control over memory representation in order to achieve something
> approximating performance parity with native audio applications. int16
> samples aren't ever going to be the default (right???) so it's not as if
> the average web developer's going to shoot themselves in the foot without
> realizing it - if they opt into int16 in a way that harms them, that is
> unfortunate, but it doesn't mean that the actual use cases for int16 aren't
> justified.
>
> If int16 buffers don't offer something approximating actual guarantees,
> you haven't fixed anything - that native port will still have to assume the
> worst (i.e. using 2x as much memory) and be rewritten to work with a tiny
> address space, making your int16 buffer optimization nearly meaningless -
> sure, the mixer might be slightly faster/slower and the process's resident
> memory use will be lower, but it won't enable any new use cases and certain
> ports will still be out of the question.
>
> P.S. on this subject, does Web Audio allocate memory out of the JS heap in
> Safari, Chrome or Firefox? It's already bad enough that in many cases it's
> not possible to allocate more than 1GB of RAM in user javascript; if Web
> Audio is eating away at that with 32-bit samples...
>

Of course AudioBufferSources live on the JS heap.  I think for most others
in Safari and Chrome, memory does not come from the JS heap.