New issue
Advanced search Search tips

Issue 819670 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 9
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

HRTF output differs between M65 (beta) and ToT today

Project Member Reported by rtoy@chromium.org, Mar 7 2018

Issue description

Visit hoch.github.io/canopy and paste this code into the code window:

/ @channels 2
// @sampleRate 32768
// @duration 1

let nodeName = 'PannerNode';
let nodeOptions = {panningModel: 'HRTF', distanceMode: 'linear'};

// Merge channels for the destination.
let merger = new ChannelMergerNode(context, {numberOfInputs: 2});
merger.connect(context.destination);

let src = new ConstantSourceNode(context, {offset: 1});

// Impulse for testing.  We want a full buffer so as not to worry about
// the source disconnecting prematurely from the filter.
let b = new AudioBuffer(
    {length: context.length, sampleRate: context.sampleRate});
b.getChannelData(0)[0] = 1;
let impulse = new AudioBufferSourceNode(context, {buffer: b});

let testNode = new window[nodeName](context, nodeOptions);
let refNode = new window[nodeName](context, nodeOptions);

src.connect(testNode).connect(merger, 0, 0);
impulse.connect(refNode).connect(merger, 0, 1);

src.start();
src.stop(1 / context.sampleRate);
impulse.start();

Run it and examine the output waveforms.  In 65, channel 0 is silent. In ToT, channel 0 is not.

This is unexpected.
 

Comment 1 by rtoy@chromium.org, Mar 7 2018

Blocking: 357843

Comment 3 by rtoy@chromium.org, Mar 9 2018

If we revert the change, I see that the src signals the source has finished processing and puts the AudioHandler on finished_source_handlers at context time 0.  Then cleanup happens and breaks the connection between that node and the downstream nodes. This happens at time 0.

However, with the current version using finished_source_handlers, breaking the connection happens at time 0.0078125, 256 frames later.

But recall that the cleanup happens on the main thread, unsynchronized with the audio thread.  And since this is an offline context, it runs really fast.  So it's certainly possible for the main thread to be a little slow in getting the message and cleaning up the handlers.  

Comment 4 by rtoy@chromium.org, Mar 9 2018

Blocking: -357843
This doesn't block tail processing ( issue 357843 )
Status: WontFix (was: Assigned)
Leave it as is.

Sign in to add a comment