Re: Integer PCM sample formats to Web Audio API?

On Wed, Jan 15, 2014 at 1:36 PM, Raymond Toy <rtoy@google.com> wrote:

>
> But you, as the web audio app author, can't control the sample rate of the
> device it is playing on.  Even on the same machine, the machine owner could
> have changed the local audio device to be 44.1 kHz today, but tomorrow he
> might change it to 88 kHz. Should your app suddenly sound funny the next
> day? If not doing resampling is important, you'd have to supply all of your
> assets in different sampling rates. (Which might be a good idea anyway, if
> you can afford the storage and bandwidth.)
>

I'm talking about source rates, not mixing rates. I made this very explicit
in my email. I don't know why you think I was talking about controlling the
mixing rate.


>
> It's not just a minor efficiency optimization.  Some of the algorithms are
> quite complex, so implementing them in fixed-point would be particularly
> painful. The existence of a biquad filter with, essentially, unlimited huge
> peaking can suddenly cause something that was nice to suddenly either clip
> or roll-around causing terrible glitching.  Yes, this is solvable, but
> int16 makes the internal implementation much, much more difficult, prone to
> bugs, and many more round-off effects.
>
> For controlled applications, fixed-point is ok.  For something as open as
> WebAudio, floating-point is a natural choice.
>
> I know Chris Rogers wanted to be able to use WebAudio for pro-audio
> applications where (I think) 24-bit or floating-point samples are the norm.
> Forcing int16 internally prevents this completely.
>
>
Why would you implement the filters in fixed-point? Nobody has suggested
this. You'd convert int16 samples up to float32 before mixing them in the
mixer. If the cost of doing the conversion in realtime is too high, you
could maintain a small fixed-size pool of decoded samples (int16->float32,
etc), and when the buffer gets too full you can do your mix in multiple
passes. (I doubt that the cost of some int16->float32 conversions for
samples is really that significant on typical desktop configurations,
especially using SIMD; I can't comment on mobile.)

Your point about 24-bit samples makes no sense to me. Is anyone talking
about forcing everything to use int16? We're talking about being able to
decode audio into int16 samples (especially if it contained int16 samples
to begin with) and storing them in AudioBuffers as 16-bit samples. This
doesn't mean that the mixer stops using float32 or that we drop support for
float32, I don't know why it would.