Re: Integer PCM sample formats to Web Audio API?

Ok, I marked this down as
https://github.com/WebAudio/web-audio-api/issues/283 .

   Jukka



2014/1/15 K. Gadd <kg@luminance.org>

>
>
>
> 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.
>