[Webkit-unassigned] [Bug 218261] NotSupportedError thrown assigning ConvolverNode buffer

[bugzilla-daemon at webkit.org]

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

--- Comment #7 from Chris Dumez <cdumez at apple.com> ---
(In reply to Chris Dumez from comment #6)
> (In reply to Ashley Gullen from comment #5)
> > I think it's the first reason (different sample rate). In Chrome, Firefox
> > and Safari I get an AudioContext running at 44.1KHz (the default, we don't
> > specify a sample rate). In Chrome and Firefox the audio buffer we assign to
> > the convolver node is also 44.1KHz, presumably because it came from the
> > AudioContext's decodeAudioData which knew to resample it. However our audio
> > files are all WebM Opus - it's nearly supported in all browsers, but Safari
> > is the last browser that does not support this format. So we have to ship a
> > WebAssembly WebM Opus decoder just for Safari. But this decoder outputs
> > audio buffers at a fixed sample rate of 48 KHz, hence the mismatch. (I guess
> > your system's sample rate defaulted to 48 KHz so it matched?)
> > 
> > Does the spec say the sample rate has to match? It doesn't seem to be a
> > problem anywhere else in the Web Audio API, just with this specific case.
> 
> Yes, it does:
> https://webaudio.github.io/web-audio-api/#dom-convolvernode-buffer
> 
> """
> When setting the buffer attribute, execute the following steps synchronously:
> If the buffer number of channels is not 1, 2, 4, or if the sample-rate of
> the buffer is not the same as the sample-rate of its associated
> BaseAudioContext, a NotSupportedError MUST be thrown.
> """

Interestingly, Chrome has the exact same check as us:
https://github.com/chromium/chromium/blob/a5484e6310a38223fde757b6f094a673ce032cc0/third_party/blink/renderer/modules/webaudio/convolver_node.cc#L117

I am therefore surprised it is throwing in Safari but not Chrome. Maybe the AudioContext ends up with the different sample rate on Safari and Chrome?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20201027/435b0390/attachment.htm>