Describe the feature
Perhaps for a) a boolean property and an event emission (in case e.g. element.currentSrc changed from same-origin to cross-origin or vice versa) would do.
b) is needed in order to not "break" the element whose src is CORS-restricted so at least it is possible for the user to hear its sound.
It also can come in handy if you decided to switch to a different AudioContext (e.g. you don't like sampleRate or latencyHint of the current one).
Or perhaps createMediaElementSource needs to be replaced with something that doesn't cause this trouble.
Is there a prototype?
No.
Describe the feature in more detail
For context, I'm developing an extension which calls AudioContext.createMediaElementSource for every media element on every page.
As we know, cross-origin media playback is allowed, but MediaElementAudioSourceNode outputs zeroes for such media (https://webaudio.github.io/web-audio-api/#MediaElementAudioSourceOptions-security), which means that when you call createMediaElementSource for such media it simply gets muted with no conservative (meaning without re-creating the element or something like this) way to revert it, which (at least in my case) is worse than not calling the method at all.
Some websites fetch media data from a different origin (and even a different subdomain is a different origin - see, for example, Zoom recordings), but the Access-Control-Allow-Origin header is not always applied to such media responses, which makes createMediaElementSource (therefore my extension) not only useless but even harmful.
In a perfect world it would also be nice if createMediaElementSource always just worked for browser extensions somehow. Web Audio API may not be the only scope this issue lies in in this case (then I would appreciate if someone gave me directions on how to proceed).
And FYI I'm not the greatest web guru, I may just be missing something.
Describe the feature
Perhaps for a) a boolean property and an event emission (in case e.g.
element.currentSrcchanged from same-origin to cross-origin or vice versa) would do.b) is needed in order to not "break" the element whose
srcis CORS-restricted so at least it is possible for the user to hear its sound.It also can come in handy if you decided to switch to a different
AudioContext(e.g. you don't likesampleRateorlatencyHintof the current one).Or perhaps
createMediaElementSourceneeds to be replaced with something that doesn't cause this trouble.Is there a prototype?
No.
Describe the feature in more detail
For context, I'm developing an extension which calls
AudioContext.createMediaElementSourcefor every media element on every page.As we know, cross-origin media playback is allowed, but
MediaElementAudioSourceNodeoutputs zeroes for such media (https://webaudio.github.io/web-audio-api/#MediaElementAudioSourceOptions-security), which means that when you callcreateMediaElementSourcefor such media it simply gets muted with no conservative (meaning without re-creating the element or something like this) way to revert it, which (at least in my case) is worse than not calling the method at all.Some websites fetch media data from a different origin (and even a different subdomain is a different origin - see, for example, Zoom recordings), but the
Access-Control-Allow-Originheader is not always applied to such media responses, which makescreateMediaElementSource(therefore my extension) not only useless but even harmful.In a perfect world it would also be nice if
createMediaElementSourcealways just worked for browser extensions somehow. Web Audio API may not be the only scope this issue lies in in this case (then I would appreciate if someone gave me directions on how to proceed).And FYI I'm not the greatest web guru, I may just be missing something.