[Webkit-unassigned] [Bug 154538] Web Audio restores wrong sample rate and sounds distorted

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=154538

--- Comment #5 from Jer Noble <jer.noble at apple.com> ---
(In reply to comment #4)
> Hi Jer, thanks for looking in to this. However I'm a little confused by your
> response. When you say "you will still have to deal with a 48kHz sample
> rate", are you addressing that to web developers? As far as I am aware,
> there is no other platform that requires us to have to care about the output
> sample rate, since in general any content at a different sample rate is just
> automatically resampled to the output sample rate if necessary. In fact the
> Web Audio API spec states regarding decodeAudioData: "Take the result,
> representing the decoded linear PCM audio data, and resample it to the
> sample-rate of the AudioContext if it is different from the sample-rate of
> audioData." So this appears to be an explicit requirement that Safari's
> implementation should be complying with.

All I'm saying is that Web Audio developers can't assume that the output sample rate will always be 44.1kHz.  If they are manually creating and filling buffers assuming that the sample rate is 44.1kHz (when instead it's 48kHz), they could playback artifacts.  Say, for example, if they were implementing a grain-based player; they could conceivably have gaps between the grains if their sample-rate assumptions were invalid.

> If we have to do anything differently to handle this, firstly I think iOS
> would be unique in that regard, which creates a web compatibility issue.
> Secondly I am not even sure what we would do differently in terms of the Web
> Audio API? Are we supposed to throw away all our buffers and re-decode them
> or something? The problem happens on startup, so it's a mystery to me what
> we would need to do differently and under what circumstances we ought to do
> it.

I'm pointing out a situation where the hardware audio sample rate could change dynamically within the lifetime of an AudioContext. A iPhone user could unplug their headphones, the active route would change to the internal speaker, and the audio hardware would switch up from 44.1kHz to 48kHz.  There is API in the spec to signal such a rate change, so WebKit would have to resample the Web Audio output in that case.

> If I were to hazard a guess as to what's really going on, I'd guess Safari
> mistakes the output sample rate for 48 KHz when it's really 44.1 KHz, and
> accordingly decodeAudioData is resampled to the wrong rate, or something
> like that.

It very well may be, though I think it's more likely that, at the time the AudioContext was created, the hardware sample rate really was 48k, but that the hardware sample rate changed sometime after playback began.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160224/e0e2818d/attachment.html>