Failed to execute 'createMediaElementSource' on 'BaseAudioContext': HTMLMediaElement already connected previously to a different MediaElementSourceNode after close audioContext
Reported by
iagoalon...@gmail.com,
Jun 10 2018
|
|||
Issue description
Chrome Version : 67.0.3396.79 (Build oficial) (64 bits)
OS Version: Linux
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari: Not tested but it's based on WebKit so I expect FAIL.
Firefox: OK
IE/Edge: FAIL
What steps will reproduce the problem?
1. Create a div with an audio tag:
<audio id="songs" crossorigin="anonymous" preload="none">This API it's not supported on your browser</audio>
2. Create an audio context:
context.createMediaElementSource(audio);
3. Play a song and try to do previus/next:
Even you close the context after press previus/next
context.close();
when this line it's reached again
context.createMediaElementSource(audio);
the sound stops and on the console it's displayed:
Failed to execute 'createMediaElementSource' on 'BaseAudioContext':
HTMLMediaElement already connected previously to a different MediaElementSourceNode.
What is the expected result?
Be able to play a song list.
What happens instead of that?
Only it's possible to reproduce 1 song.
Please provide any additional information below. Attach a screenshot if
possible.
You can see my full question on StackOverflow, someone suggested me to put this issue:
https://stackoverflow.com/questions/50657659/different-behaviour-of-webaudio-api-on-google-chrome/
,
Jun 11 2018
Hi, you can find the code of my project and download it on this commit. If you open it on Chrome and try to do next/previous you will see the failure on the console. https://github.com/MinionAttack/webCV/tree/42037398c75b789a6280baf2e1a6c1371e44ebf0
,
Jun 11 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 11 2018
Ups, sorry, the correct commit it's: https://github.com/MinionAttack/webCV/tree/6c023939ba8f3f67627b43182e59d01872911f16 You need to add this file to the js folder, and you don't have to worry about find music to test this issue: http://www.2ndrenais.com/aetherplayer/assets/aetherplayer/js/playlist.js
,
Jun 11 2018
The spec is not really clear about the behavior of BAC and MESN when they are gone or closed. https://github.com/WebAudio/web-audio-api/issues/1202 Of course Chrome can do its service by cleaning up when the context goes away but there is an implication of the GC observability, so we need a discussion before implementing such behavior.
,
Jun 11 2018
I don't think GC has any bearing on the issue. Consider this:
a = new Audio();
c0 = new AudioContext();
c1 = new AudioContext();
n0 = new MediaElementAudioSourceNode(c0, {mediaElement: a})
n0.connect(c0.destination);
c0.close()
/* wait a bit for c0 to close; I'm lazy here. */
n1 = new MediaElementAudioSourceNode(c1, {mediaElement: a})
This produces an error:
Uncaught DOMException: Failed to construct 'MediaElementAudioSourceNode': HTMLMediaElement already connected previously to a different MediaElementSourceNode.
While connecting on audio element to two different MEASN's on two different contexts might be problematic, one of these is closed and the connection ought to be cleared.
If we fix it so that an element can be connected to more than one MEASN, this particular issue would probably also get fixed.
,
Jun 11 2018
The GC problem that I was talking about is the WG spec issue. This bug(?) is closely related to the resolution of the spec issue. |
|||
►
Sign in to add a comment |
|||
Comment 1 by krajshree@chromium.org
, Jun 11 2018Components: Blink>WebAudio
Labels: Needs-Feedback Triaged-ET Needs-Triage-M67