Unable to reproduce the issue in Mac 10.12.2 by using chrome reported version #54.0.2840.98 and latest canary #57.0.2952.0.

Steps followed to reproduce the issue are as follows:
-----------
1. Navigated to the URL: https://jsfiddle.net/Sambego/op79c5xb/7/
2. Observed that an AudioBuffer was created without any issues.

Attaching screen cast for reference.

sambellen@ - Could you please check this issue on latest chrome stable #55.0.2883.87 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.
The latest stable can be downloaded from the following link:
https://www.chromium.org/getting-involved/dev-channel

Thanks...!!

Deleted: 673782.mp4 1.4 MB

	673782.mp4 1.4 MB View Download

I tested it in both the latest stable chrome (55.0.2883.95 (64-bit)) and the latest canary (57.0.2953.0 canary (64-bit)), but the error seems to be persist in both of them.

I've attached a screenshot of the console output of the jsfiddle.

It might be worth mentioning that this error is also present when changing to other audio codec's, but when trying to load an external .ogg file, it works as expected.
I tested with this file 'https://upload.wikimedia.org/wikipedia/en/4/45/ACDC_-_Back_In_Black-sample.ogg`.

Deleted: Screen Shot 2016-12-16 at 09.50.08.png 134 KB

	Screen Shot 2016-12-16 at 09.50.08.png 134 KB View Download

Deleted: Screen Shot 2016-12-16 at 09.48.13.png 81.5 KB

	Screen Shot 2016-12-16 at 09.48.13.png 81.5 KB View Download

I can confirm the issue using ToT chromium.  I thought MediaRecorder only supported Opus files, and webaudio couldn't decode Opus-encoded files until just a few weeks ago.  Nevertheless, ToT chromium can support Opus-encoded files.

Tested on Mac OS 10.12.1 using latest chrome M57 #57.0.2956.0 and able to create the audio buffer.

Attached screencast for reference.

Thanks!

Deleted: 673782.mp4 320 KB

	673782.mp4 320 KB View Download

Maybe the audio component in the jsfiddle is a bit confusing, but it is to demonstrate that chrome can handle the opus codec, at least when using it with an audio element.

According to this issue, which got merged earlier this month the decodeAudioData method should be able to handle opus: https://bugs.chromium.org/p/chromium/issues/detail?id=482934

The audio recorded by the MediaRecorder is playable by the audio component when converted to a blob data url.

However, when you want to convert that blob to an audio-buffer using audioContext.decodeAudioData(buffer) it fails.

This part of the code fetches the blob data url and converts it into an array-buffer. That works fine, but the next step is to convert that array-buffer into an audio-buffer, and that is where chrome fails.

The audioContext.decodeAudioData method accepts an array-buffer, but for some reason can not handle the array-buffer created from the blog of the recording created earlier.

// Fetch the blob's data-url
fetch(blobDataUrl).then(response => {
    // Works well, the data-url gets fetched
    return response.arrayBuffer();
}).then(buffer => {
    // Converting the data-url to an array-buffer works as expected
    return audioContext.decodeAudioData(buffer);
}).then(data => {
    // we expect an audio-buffer here, but chrome fails to convert the array-buffer
    // to an audio buffer, so we end op in the error callback of the promise.
}, error => {
    // Chrome throws this error:
    // error DOMException: Unable to decode audio data
});

You can see the output of each step when opening the console in the developer tools.

I hope this explains the issue more in detail.

Yes, I was seeing exactly that. I don't understand why the array buffer doesn't work.  Will need to examine the contents of the buffer to see why ffmpeg doesn't like it.

rtoy@, are you the right owner for this issue?

Someone on the WebAudio team will look into this. Possibly me, but not necessarily.

Could be the same root cause as  https://crbug.com/606000 .

sambellen@, just to be sure, downloading the whole
recording can be correctly played in either Chrome or an
external player, e.g. vlc?

mcasas@ Yep the recording can be played in both Chrome and VLC.

You can find a sample of a recording here: https://www.dropbox.com/s/4gp2b8cdxyrjzdy/myrecording.mp4?dl=0

Bulk move
Blink>MediaStream>Recording ---> Blink>MediaRecording

ping rtoy@, sambellen@ any updates here?

There's been a few actions and a major update to libwebm,
so perhaps anyone could try again?

mcasas@, does not seem to be fixed.
Tested on both the latest stable Chrome version and canary.

dalecurtis:  Since MediaRecorder saves files in webm format, this means WebAudio needs ffmpeg to support webm, right?  As best as I can tell, Chrome's ffmpeg doesn't.

AudioFileReader definitely supports webm; you'll have to add some logging to figure out why it's not working. I'd guess there's a parse error or we're not handling data:// URLs properly in AudioFileReader.

Thanks Dale.  It's failing because the duration is not specified (at least for the test file I'm using).  Then AudioFileReader::Open() returns false indicating that we can't read the file.  

I guess that means we'll need to modify DecodeAudioFileData to be able to read the data into an internal bus that grows as needed and copy it to the destination bus.

Does that sound right?

Correct, you'd need to setup a method for streaming decode.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3489b2812bf4e670cc27627ee9a7a1fd1919f399

commit 3489b2812bf4e670cc27627ee9a7a1fd1919f399
Author: rtoy <rtoy@chromium.org>
Date: Fri Feb 10 18:15:55 2017

Decode entire in-memory file for WebAudio

DecodeAudioFileData assumed that any in-memory file to be decoded had
a known duration that could be estimated without reading the entire
file.  For webm files produced by MediaRecorder, this can be false.

Read and decode the entire file, ignoring any estimated duration.  This
will result in increased memory consumption because the final output
is built up in pieces before finally copying it to the final destination.

Add tests for decoding webm files and WAV files using float32 samples.
Vorbis tests need to be updated because the resulting outputs were
previously truncated.

BUG= 673782 
TEST=codec-tests/webm/webm-decode.html, codec-tests/wav/f32-44khz.html

Review-Url: https://codereview.chromium.org/2655783004
Cr-Commit-Position: refs/heads/master@{#449662}

[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/content/renderer/media/audio_decoder.cc
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/media/filters/audio_file_reader.cc
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/media/filters/audio_file_reader.h
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/media/filters/audio_file_reader_unittest.cc
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/vorbis/vbr-128kbps-44khz-expected.wav
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/vorbis/vbr-70kbps-44khz-expected.wav
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/vorbis/vbr-96kbps-44khz-expected.wav
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/wav/f32-44khz-expected.wav
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/wav/f32-44khz.html
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/webm/test-webm.webm
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/webm/webm-decode-expected.wav
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/codec-tests/webm/webm-decode.html
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/decodeAudioData/decode-audio-data-basic-expected.txt
[modify] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/decodeAudioData/decode-audio-data-basic.html
[add] https://crrev.com/3489b2812bf4e670cc27627ee9a7a1fd1919f399/third_party/WebKit/LayoutTests/webaudio/resources/media/f32-44khz.wav

rtoy@/sambellen@ did #25 solve the problem? Can we mark this as Fixed?

I.e. is https://jsfiddle.net/Sambego/op79c5xb/7/ working fine now
with the latest Canary? -- seems to work fine to me.

Yes, #25 was intended to solve this problem (and some others).

Hey all,

Has the fix hit version 57? I'm still encountering this issue on Windows and Ubuntu when fetching the object URL of a Blob, captured via the MediaRecorder API, as an ArrayBuffer.

https://github.com/learnable-content/jamesseanwright/blob/web-audio/webrtc/complete/index.js

Thanks,
James

#29 - Chrome 58 has the fix.