Thanks for translating my garbled off-the-cuff statement. You got the sense of it. I think there used to be a loader method in the API that bypassed the need for an XHR, which led to my confusion. . . . . . ...Joe Joe Berkovitz President Noteflight LLC +1 978 314 6271 www.noteflight.com "Your music, everywhere." On Jul 23, 2013, at 5:33 PM, Chris Wilson <cwilso@google.com> wrote: > I think Joe meant "I note that decoding network files into AudioBuffers would naturally already adhere to CORS, since you'd use XHR to download them." > > > On Tue, Jul 23, 2013 at 2:28 PM, Robert O'Callahan <robert@ocallahan.org> wrote: >> On Wed, Jul 24, 2013 at 8:09 AM, Joseph Berkovitz <joe@noteflight.com> wrote: >>> Not only should we subject this to CORS rules, I think we *must* subject it to CORS rules. Audio assets are commonly delivered from CDNs and these are typically located at an origin foreign to the containing page. >> >> Sure. However, authors will have to use the crossorigin attribute on the media element to generate a CORS-enabled request. >> >>> I note that AudioBuffer.decodeAudioData obeys CORS as a fact on the ground in both the FF implementation and Webkit/Blink. >> >> I don't see how CORS is relevant to decodeAudioData. decodeAudioData takes an ArrayBuffer, which can never be cross-origin. >> >> Rob >> -- >> Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w >
Received on Tuesday, 23 July 2013 22:00:12 UTC