New issue
Advanced search Search tips

Issue 732340 link

Starred by 6 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jun 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

FileSystem Writer writing empty audio files

Reported by asherco...@audyx.com, Jun 12 2017

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.86 Safari/537.36

Steps to reproduce the problem:
1. Go to https://fiddle.jshell.net/ashercoren/2zo7kd9q/1/
2. Wait for "file saved!" to be printed to console
3. Click PLAY FROM FILE SYSTEM button

What is the expected behavior?
The audio file should play

What went wrong?
An error is printed to the console: Uncaught (in promise) DOMException: Unable to decode audio data.
When viewing the saved files (using the fileSystem extention - see link in comment), the file is empty.

Did this work before? Yes 58

Does this work in other browsers? Yes

Chrome version: 59.0.3071.86  Channel: stable
OS Version: 10
Flash Version: 

The file system can be viewed using this extension: https://chrome.google.com/webstore/detail/html5-filesystem-explorer/chkmbbajnboncdmkigkgpjdhppcjhlcc?
 

Comment 1 by jsb...@chromium.org, Jun 12 2017

Components: -Blink>FileAPI Blink>Storage>FileSystem

Comment 2 by jsb...@chromium.org, Jun 12 2017

Components: -Blink>Storage>FileSystem Blink>WebAudio
Status: WontFix (was: Unconfirmed)
In the fiddle, at the point where saveFile(xhr.response) is called, xhr.response.byteLength is 0, so a zero-length file is written.

It looks like audioCtx.decodeAudioData(xhr.response, ...) is detaching the buffer:

https://webaudio.github.io/web-audio-api/#widl-BaseAudioContext-decodeAudioData-Promise-AudioBuffer--ArrayBuffer-audioData-DecodeSuccessCallback-successCallback-DecodeErrorCallback-errorCallback

"...If the operation IsDetachedBuffer ... on audioData is false, execute the following steps: ... Detach the audioData ArrayBuffer...."

So after calling decodeAudioData, xhr.response is expected to be empty.

Comment 3 by rtoy@chromium.org, Jun 12 2017

Yes, this is the spec'ed behavior recently implemented in Chrome.

I personally don't really like this, but I understand why this is done. (Don't want to allow users to muck with the buffer while the async decodeAudioData is decoding.)
Thank you.
I was able to fix my fiddle by creating the file Blob before calling decodeAudioData.

Sign in to add a comment