New issue
Advanced search Search tips

Issue 809765 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Strange glitch when disconnecting stereo source

Project Member Reported by rtoy@chromium.org, Feb 6 2018

Issue description

Run the following bit of code using hoch.github.io/canopy:

/ @channels 2
// @duration 1
// @sampleRate 25600

// Don't remix to stereo, so we can see all the channels.
context.destination.channelInterpretation = 'discrete';

let s1 = new OscillatorNode(context, {frequency: 440});
let s2 = new OscillatorNode(context, {frequency: 880});

let upmix = new GainNode(context, {channelCount: 2, channelCountMode: 'explicit'});

s1.connect(upmix);

let f = new BiquadFilterNode(context, {frequency: 1000});

s2.connect(f);

f.connect(context.destination);

s1.start();
s2.start();

if (0) {
    upmix.connect(f);
} else {
    context.suspend(1024 / context.sampleRate)
        .then(() => upmix.connect(f))
        .then(() => context.resume());
}

let stopTime = 0.25;
if (1) {
    s1.stop(stopTime);
} else {
    context.suspend(stopTime)
        .then(() => s1.disconnect())
        .then(() => context.resume());
}
 
Examine the graph at some time after 0.25 sec.  There is a strange glitch here the second channel becomes silent.

But the code never does anything at this time.  s1 is stopped at time 0.25 and that's the last time there any change in the graph.

It's as if s1 is disconnected at this time, disconnecting the gain node which disconnects from the filter.  But this is an offline context, so I was expecting the disconnects to all happen very close to 0.25 sec.

 

Comment 1 by rtoy@chromium.org, Feb 12 2018

What's happening is that stop() happens at the right time and the oscillator is placed on the list of finished sources.  However, the processing of the finished sources happens on the main thread, so this can happen at some arbitrary time after stop().  When the main thread does the cleanup, the connection is then broken between the oscillator and the down stream node, at which point the channel count actually changes.

Hence, the switch from stereo to mono depends a lot on timing and happens "randomly" after stop().

However, there is still the issue of the glitch.  This is because the change in the channel count causes the biquad filter to reinitialize it's biquad processor kernels, which causes the biquad state to be removed.  Hence, all memory of the previous signal on channel 0 is lost.

This could be fixed by preserving any memory for existing channels.

Sign in to add a comment