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

commit fef049ce3cbf105e7e1fb6402fe8b5727b38846d
Author: Adam Rice <ricea@chromium.org>
Date: Fri Nov 30 11:53:09 2018

Don't enable transferable streams for AudioWorklet

AudioWorklet has "MessagePort" on the global object but not
"DOMException". The V8 Extras transferable streams implementation needs
"DOMException" to be on the global object so that it can copy it to the
bindings object and construct a DOMException when an object cannot be
cloned.

Disable transferable streams for audio worklet by not copying
"MessagePort" to the bindings object.

BUG=894838,910471

Change-Id: Ia3bd3a5610d4aa442671fab1c1dc9f20c5c4c5e9
Reviewed-on: https://chromium-review.googlesource.com/c/1356462
Reviewed-by: Yuki Shiino <yukishiino@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Adam Rice <ricea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#612618}
[modify] https://crrev.com/fef049ce3cbf105e7e1fb6402fe8b5727b38846d/third_party/blink/renderer/bindings/core/v8/initialize_v8_extras_binding.cc

The related spec issue:
https://github.com/WebAudio/web-audio-api/issues/1282

tl;dr:
WorkletGlobalScope does not have a proper error handling mechanism yet.

We can make AudioWorkletGlobalScope support DOMException in the scope, but that needs a spec change. Currently it is only exposed in Window and Worker. (https://heycam.github.io/webidl/#idl-DOMException)

Should we mark this as "ExternalDepedency"? I am not sure.

What happens if you pass a non-transferable type to messagePort.postMessage() inside an AudioWorklet? Normally that would throw a DOMException.

+1 to ricea@'s question in comment #4.

I think we should make the tiny spec change to add Exposed=Worklet or Exposed=AudioWorklet, at least.

ricea@

A dumb question. What can you do with this "transferred stream" object in AudioWorkletGlobalScope? I believe the stream does not expose any audio sample data.

Any kind of data can be passed through a stream, although transferrable streams are limited to types that can be cloned. I am envisioning people wanting to stream audio data.

> I am envisioning people wanting to stream audio data.

Please correct me if I am wrong - I am not familiar with the concept of Stream object, but it won't be compatible with the processing model of Web Audio API and Audio Worklet work. From the "transferable stream" perspective, Audio Worklet is just another form of worker.

With that said, it's not a big change as domenic@ said so I am not opposed to it. Perhaps the spec change should come first?