7

I'm using ScriptProcessorNode's onaudioprocess callback to process the microphone input. By connecting MediaStreamSourceNode to the ScriptProcessorNode, I can get the raw audio data within the onaudioprocess callback function. However, after about 30 seconds (this varies ranging from 10 to 35 sec,) the browser stops calling onaudioprocess. In the following code, the console.log output ('>>') always stops after about 30 sec.

var ctx = new AudioContext();
var BUFFER_LENGTH = 4096;
console.log('Buffer length is + ' + BUFFER_LENGTH);
navigator.webkitGetUserMedia({audio: true}, function (stream) {
    var mediaStreamSource = ctx.createMediaStreamSource(stream);
    var scriptProcessor = ctx.createScriptProcessor(BUFFER_LENGTH, 1, 1);
    scriptProcessor.onaudioprocess = function (e) {
      console.log('>>');
    };
    scriptProcessor.connect(ctx.destination);
}, function(e) {
  console.error('Unable to get audio input source.');
});

I tried all the possible BUFFER_LENGTH (256, 512, 1024, 2048, 4096, 8192, 16384), but the situation didn't change (log stops after 30 sec.) I observed this issue in the latest Chrome Release (Version 35.0.1916.153) and Canary (Version 37.0.2060.3 canary.) Does anyone know any workarounds?

kuu
  • 815
  • 1
  • 7
  • 16
  • I'm wondering if it has to do with the fact that you're returning empty e.outputbuffers in your onaudioprocess callbacks. After 30 seconds on seeing empty buffers Chrome may want to save battery/processing power and turn off the callback. – notthetup Jun 21 '14 at 10:55
  • Thanks notthetup, I tried copying the inputBuffer to outputBuffer in onaudioprocess. But it didn't fix the issue. Heres the code: var source = e.inputBuffer.getChannelData(0); var dest = e.outputBuffer.getChannelData(0); dest.set(source); – kuu Jun 22 '14 at 13:46

1 Answers1

23

This looks more like your scriptprocessor object is getting garbage collected. Try saving it in a global variable and see if that fixes the problem.

cwilso
  • 13,610
  • 1
  • 30
  • 35
  • Thank you Chris. As you said, saving ScriptProcessorNode in a global variable fixed this issue. But I think this behavior (garbage collecting a still connected node) needs to be fixed. Has this already been filed as a bug? – kuu Jun 22 '14 at 13:11
  • 1
    If I'm remembering correctly, the AudioContext destination doesn't maintain a reference to the ScriptProcessor. So garbage collection of the ScriptProcessor is actually appropriate here, because nothing has a reference to it. – Kevin Ennis Jun 22 '14 at 14:12
  • I found an open bug that seems to be related to this issue: https://bugs.webkit.org/show_bug.cgi?id=112521 It looks like a patch was suggested last year, but it's not yet accepted. – kuu Jun 22 '14 at 15:02
  • The spec states that: "Any AudioNodes which are connected in a cycle and are directly or indirectly connected to the AudioDestinationNode of the AudioContext will stay alive as long as the AudioContext is alive." http://www.w3.org/TR/webaudio/#lifetime-AudioNode – kuu Jun 23 '14 at 03:20
  • I found this chrome bug (still Untriaged): https://code.google.com/p/chromium/issues/detail?id=360378 – rashtao Jun 23 '14 at 06:18