Thanks for filing the issue!

@Reporter: Could you please share a sample test file/URL which satisfies the conditions mentioned in comment#0. Any further inputs from your end may be helpful.

Here is a link to a demo which replicates the issue to the best of my ability, if there is something fundamentally wrong with my code please let me know. 

https://jsfiddle.net/tannerfoster/jtq2wypv/49/

Instructions: 
1. Run the code 
2. Observe white noise being generated
3. Once white noise is complete name the audio file.
4. Use the gui to try and replay the audio and observe silence.
5. Download the generated audio file and play it independent of the browser.
6. Observe more silence.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Tried testing the issue on reported chrome version 70.0.3538.77 using Windows 10 with the below mentioned steps.
1. Launched Chrome
2. Navigated to https://jsfiddle.net/tannerfoster/jtq2wypv/49/
3. Clicked Run -> Heard the noise being generated.
4. Named the Audio file after the noise is complete.
5. Clicked on play button, Observed silence.
6. Downloaded the file and played through an other application(...VLC Player)

@Reporter: We even observed silence, while the file is played in VLC, isn't that the expected behaviour? As we are not very sure about the expected behaviour, Could you please confirm on the same.

Thanks!

I'm sorry, the proper behavior is that when you hit the play button after you name the file you should hear the same white noise again and you should hear the same white noise when you download the file and play it locally. The observed behavior in chrome 70 is silence. Does that clear it up?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@Reporter: Thanks for the confirmation.....!

Able to reproduce the issue on reported chrome version 70.0.3538.77 and on the latest canary 72.0.3616.0 using Windows 10, Ubuntu 14.04 and Mac 10.14.1

Bisect Information:
-------------------
Good Build: 65.0.3311.0
Bad Build:  65.0.3312.0

You are probably looking for a change made after 527050 (known good), but no later than 527057 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/0a002495ffc9bb326b362fdedf93620dd8fc553e..b910d51d757bc376356d333812c0dc595f7a7beb
Suspecting: https://chromium.googlesource.com/chromium/src/+/3e186bcbdb3b5bc1eb70e132a02776a1fa8241aa
Review URL: https://chromium-review.googlesource.com/c/chromium/src/+/833008/

@Hongchan Choi: Requesting you to help in assigning it to the right owner, if this isn't related to your change.
Assigning it to Hongchan Choi (Reviewer)as Raymond Toy is OOO.

Thanks!

Let me go through the code:

// This creates mono-channel buffer.
var audioBuffer = this.audioCtx.createBuffer(1, 100000, 16000);

// The mono buffer source node is connected to a 2-channel splitter.
this.bufferSource = this.audioCtx.createBufferSource();
var splitterNode = this.audioCtx.createChannelSplitter(2);
this.bufferSource.buffer = audioBuffer;
this.bufferSource.connect(splitterNode);

// Each output of the splitter node goes to
// 0) audio context's destination and
// 1) stream destination respectively.
splitterNode.connect(this.audioCtx.destination, 0);
splitterNode.connect(this.audioDestNode, 1);

* At this point, the stream destination will be silent.

To make this code work as you intended, the last line above should be:
splitterNode.connect(this.audioDestNode, 0);

Or better yet, you do not need a ChannelSplitter at all.

Let me know if you have more questions, but otherwise this seems like WAI.

The issue here is the repro code relied on the incorrect behavior. We fixed the bug found in the code (with the CL in #8) and I think it affected some applications that use the wrong behavior.

Fortunately, the solution (in #9) is easy enough to do in this case.

I will wait for few more days and close it as WontFix if there's no feedback.

Thank you for the feedback, I have tested it working in the demo code and will work to implement it in our production system when it is back up and running. I was completely mistaken as to the function of a splitter node, thank you for the clarification.

Glad it worked out. Still I am trying to figure out why the repro code worked before the change in #22, but I think it is okay to close this issue as WontFix.

The NextAction date has arrived: 2018-12-05