Inconsistent audio output between interactive and offline contexts when using Synths with Fat Oscillators

[gerardsmyth]

Hi,

We are noticing inconsistent behaviour when using Fat Oscillators in a synth, and were wondering if you may be able to help.

Please see the example at https://codepen.io/GerardS/pen/pvoeqRy

This has two options, one that plays a single note on a synth in the interactive context, and one which does the same in an offline context, and then plays the resulting buffer.

These should sound the same, but we are noticing that they often do not. This may be browser specific, and we are not sure of an exact pattern, but we have seen problems in Chromium and Safari browsers.

Interestingly, when the two sounds differ, if you refresh, and first try the offline option, and then the interactive one, it will likely be the offline option that gives the right output, with the interactive sound being broken.

We are only seeing these issues with the ‘fat’ oscillator types, and have not noticed it with the other options.

Any help or guidance you can provide would be much appreciated.

Regards,
Gerard
www.dappledark.com

[marcelblum]

Seems like if you set the OfflineContext sample rate to be equal to the default rate instead of explicitly setting 44100, so use Tone.getContext().sampleRate instead, the problem goes away.

[gerardsmyth]

Thanks Marcel. Setting the sample rate to 48k does seem to resolve the sound issues.
Is this behaviour you would expect? I would not have thought a relatively minor change to sample rate would have such a large affect on the resulting audio.

Thanks again for your help.

[marcelblum]

It's not the *expected* behavior, but it works 🤷. I think I had stumbled onto this a while back and concluded it was a blink/webkit implementation bug since it does not occur in Firefox (note that a lot of original web audio API source code was written for webkit before the blink fork and there are remnants still in blink so it's not uncommon for web audio bugs to be shared between safari and chrome). Like some buffer size is being miscalculated when differing sample rate contexts are in use. I never pursued it further but might be worth filing a bug with the Chromium team though you'd have to boil it down to vanilla js minus Tone and standardized-audio-context. Might be worth testing in Tone with a native context (non standardized-audio-context) just to make sure the problem isn't in coming from that layer.