A little more info on this: as the MediaRecorder recording loses data, the timecode parameter of MediaRecorder.ondataavailable is not adjusting to compensate for this.

For example, in a test recording of duration 1h 55min 10s (6910000ms), the timecode value at the conclusion of the recording allows us to compute an expected duration of 6910180, however the actual recorded file duration is 6903615 (1hr 55min 4s). The timecode is correct, but the recording itself is not.

As per the original comment mentioned by user there is a similar  issue 734290  assigned to @hongchan, so cc'ing the same dev for more updates on this issue.

hongchan@ Could you please take a look in to this issue?

Thanks!

brajkumar@

I would like to help, but I don't work on MediaRecorder.

douggerhardt@

Can you clarify how MediaRecorder is set up? Are you using WebAudio before the stream goes into MediaRecorder? (not sure how you can do that though...)

Sure thing, I've got some representative code of the MediaRecorder below. We *are* also using WebAudio elsewhere; we have a second getUserMedia call on the page to the same mic, and we use audioContext.createAnalyser & getByteFrequencyData to provide a real-time VU-meter for the mic data coming out of that stream.

Here's what the MR code looks like:

var streamOptions  = {
    mandatory: {
        googEchoCancellation: false,
        googAutoGainControl: false,
        googNoiseSuppression: false,
        googHighpassFilter: false,
        sourceId: "default"         // mic device ID goes here
    }
};

var mediaRecorderOptions = { 
    audioBitsPerSecond : 96000,
    mimeType: "audio/webm;codecs=opus"
};

var dsMediaRecorder;

navigator.webkitGetUserMedia({audio: streamOptions}, function(stream) {
  dsMediaRecorder = new MediaRecorder(stream, mediaRecorderOptions);

  dsMediaRecorder.ondataavailable = function(event) {
    console.log(event.timecode);
    // store event.timecode
    // store event.data
  };

  dsMediaRecorder.onerror = function(event) { 
      throw event;
  };

  // later
  dsMediaRecorder.start(5000);

}, function(e) { 
    throw e;
});

Well, your MediaRecorder code doesn't use WebAudio at all. WebAudio is not involved in the audio recording path, that means the audio drop is not WebAudio problem.

mcasas@ Could you take a look at this and assign this to the proper owner?

MediaRecorder records whatever is being received, and given  issue 734290 
we should make sure that all the audio is correctly captured and injected
into the MediaRecorder object. IIRC getUserMedia has troubles in certain
conditions on Mac, sending choppy audio... 

Any ideas how can we detect that (hongchan@, perhaps using WebAudio?).

doug@

Why do you have two gUM() calls? Can't you have one call and share the stream object between MediaRecorder and Web Audio nodes? Just curious.

re #6 mcasas@:

Not sure. If MediaRecorder has some drop-out sample in the example above, I think the only explanation is the stream object contains such error. If that's the case, it also explains the drop-out samples in MediaStreamSourceNode + ScriptProcessorNode recorder as well because it uses the same stream object.

hongchan@:

> Why do you have two gUM() calls? Can't you have one call and share the stream object between MediaRecorder and Web Audio nodes?

We likely could. I neglected to mention above that the other getUserMedia call's stream is also handed off to WebRTC for a live call, so I do believe we're using slightly different media constraints for the call stream vs the recorded stream. We did try using a single call and sharing the stream when trying to resolve #734290 (the dropouts with the ScripProcessorNode) and it didn't seem to have any effect, so we never went further with it.

mcasas@:

I'm not sure how the MediaRecorder.ondataavailable's timecode is computed internally, but in our testing it seems like it's reflecting the idealized case (where data isn't lost). For example, in one test we called MediaRecorder.start with a 5000ms timeslice value and made a 6910000ms (1:55:10) recording on two computers. At the conclusion of the recording, the timecode value of the last data emitted indicated the proper recording duration on both computers, however one of the computers produced a recorded file that was ~4000ms too short.

When comparing timecodes for each emitted chunk of data, the computer that lost audio seemed to have a much higher variance in the chunk duration (computed as timecode - previousChunkTimecode). On the computer that made an accurate recording, these chunks averaged 5039ms with a stdev of 1.63ms; on the computer which lost audio these chunks also averaged 5039ms, but had a stdev an order of magnitude larger at 14.04ms.

A little more data:

     computer 1          | computer 2
     (correct duration)  | (incorrect duration)
Min   5031ms             | 5000ms
Max   5046ms             | 5439ms
Avg   5039ms             | 5039ms
Med   5040ms             | 5039ms
stdev 1ms                | 14ms

Any updates on this? There are numerous related issues (#796474, #787596, #734290), and seemingly no progress on a fix.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

Merging into  Issue 796474