The url: https://drive.google.com/a/google.com/file/d/1o1fkCzezhdbE6Hv9J-BdKBrDOb2TYiJf/view?usp=sharing at comment #0 need access to google account. Hence, forwarding the issue to inhouse team for further triaging of the issue.

Thanks...!!

rmanor@ Thanks for the issue.

Able to reproduce this issue on Ubuntu 14.04, Mac OS 10.12.6 and Windows 7 on the latest Chrome Stable 62.0.3202.94 and Canary 65.0.3284.0.
On playing the recording, it is read out as "Last name Randolph, R A N L P H L P H".

This is a Non-Regression issue as this is observed from M50 chrome builds. 

Hence marking this as 'Untriaged' for further updates from Dev.

Thanks...

Thanks.
Just to be clear the file I attached is the "mixed up" recording ("Last name Randolph, R A N L P H L P H") but the user has said to the microphone "Last name Randolph, R A N D O L P H".

Is the application using Web Audio API somehow? Without knowing what the application does for the recording, we can't triage the issue correctly.

Hi,

This my getUserMedia code:
    window.AudioContext = window.AudioContext || window.webkitAudioContext;

    var audio_context = new AudioContext();
    var audio_api_error = '@@@';

    var bad_mic_labels = ['@@@'];

    var getAudioStream = function(micDeviceId) {
      var constraints = {audio: true};
      if (micDeviceId) {
        constraints = {audio: {deviceId: micDeviceId}};
      }
      navigator.mediaDevices.getUserMedia(constraints)
          .then(function(stream) {
            var microphone = audio_context.createMediaStreamSource(stream);
            cb(microphone);
          })
          .catch(function(e) {
            console.log('Stream initialization error: ', e);
            alert(audio_api_error);
          });
    };
   var findUsbMicFunc = function() {
      navigator.mediaDevices.enumerateDevices()
          .then(function(deviceInfos) {
            if (ignoreMicWhitelist) {
              getAudioStream(undefined);
            } else {
              var mic_device_id = '';
              for (var i = 0; i !== deviceInfos.length; ++i) {
                if (deviceInfos[i].kind == 'audioinput' &&
                    bad_mic_labels.indexOf(deviceInfos[i].label) == -1) {
                  mic_device_id = deviceInfos[i].deviceId;
                  break;
                }
              }

              if (mic_device_id == '') {
                console.log('Could not find a USB mic.');
                alert(audio_api_error);
              } else {
                getAudioStream(mic_device_id);
              }
            }
          })
          .catch(function(e) {
            console.log('Error enumerating audio devices: ', e);
            alert(audio_api_error);
          });
    };

    // Enumerate devices for the logs.
    navigator.mediaDevices.enumerateDevices()
        .then(function(deviceInfos) {
          console.log('Enumerated devices: ', deviceInfos);
        })
        .catch(function(e) {
          console.error('Error enumerating audio devices: ', e);
        });

    // Now showing the consent prompt and calling the function chain.
    navigator.mediaDevices.getUserMedia({audio: true}).then(findUsbMicFunc)
        .catch(function(e) {
      console.log('Error getting audio consent prompt: ', e);
      alert(audio_api_error);
    });

I'm using RecorderJs to record the audio and convert it to a wave file:
https://github.com/mattdiamond/Recorderjs

The page with the recording interface is here:
https://cs.corp.google.com/piper///depot/google3/quality/views/extraction/kcube/bg/operation/recording_studio/templates/studio.html?rcl=175506042&l=445

Thanks.

Without being able to see the code behind the google wall, I can say that I have had similar issues and am using a highly hacked/modified version of recorderJs.  

The issue for me was that I was initially unaware that the scriptProcessorNode uses a single buffer between all of it's callbacks.  If you don't quickly hand off the audio in the buffer, it can be overwritten by the data contained in the subsequent onaudioprocess callback.  In my experience, the problem manifest itself in looping chunks of audio which seems to match this issue stated above.

Making quick clones of the audio buffer or promptly handing it off to a webworker for further processing seemed to solve the problem.  Hope that helps.

@jbnelsein, thanks! I'll try that.

@jbnelsein, I'm using recorderjs which seems to copy the buffer right at the start of onaudioprocess:
https://github.com/mattdiamond/Recorderjs/blob/master/src/recorder.js

Do you have an example of your change?
Thanks.

Re #6 jbenslein@:

> Without being able to see the code behind the google wall

What do you mean by this? All the WebAudio code is public.

> The issue for me was that I was initially unaware that the scriptProcessorNode uses a single buffer between all of it's callbacks.

Technically it is "double-buffered". So if your main thread gets a performance hit and misses the deadline to fill the buffer, the data can be overwritten by the audio thread. Please note that ScriptProcessorNode is deprecated from the spec for this very reason. It is under-specified and the design is inherently unstable and laggy.


Re #9 rmanor@:

I recommend to do chrome://tracing with "audio", "blink_gc", "webaudio" categories. It will visualize the area where you're having performance issues. If you upload the trace data, I can be more helpful.

What is the replacement for ScriptProcessorNode?
Thanks.

You can try this:
https://developers.google.com/web/updates/2017/12/audio-worklet

rmanor@

Were you able to test the app with AudioWorklet?

I haven't tried it yet, but so far it seems that cloning the audio buffer solved the issue.

Per #15, I am closing this issue with Wontfix. Please open a new bug if it happens again.