Re: Behavior of source nodes on connect/disconnect

FYI, I mentioned this since TC39 has repeatedly made it clear that they
won't tolerate GC observability in JS. It's a security issue that allows
communicating across realm/origin boundaries, I think.

I don't really see how you can fix it in this case other than by making an
AudioNode + ScriptProcessorNode pair an uncollectable cycle that leaks
forever if you release it. That seems kinda awful. On the other hand, maybe
it's an unusual enough use case that it's okay for it to work that way?
Alternately you can just tolerate GC visibility and see if anyone pitches a
fit about it... I don't really think it would be usable for any sort of
attack.

These behaviors regarding detached nodes and time are surprising to me - I
remember seeing slight mentions of them when I last read over the spec, but
perhaps they should be called out more clearly in an appendix of some sort
that describes the set of behaviors like this (audiobuffersourcenodes
playing while disconnected, audioprocess events firing while disconnected,
etc.)

The intent is that these behaviors are normally not observed by developers,
because all of a user's interactions with the audio API occur during a
single event loop turn, right? If an event loop turn lasts too long will
they suddenly become observable, or does mixing stop/continue using old
state? That is, if I disconnect an AudioBufferSourceNode, then spin
(blocking the content thread) for 500ms, is the disconnection observable by
someone listening to mixer output, or does it not become 'real' until the
next event loop turn? To make this contrived case more real, if I were to
connect a new AudioBufferSourceNode and then immediately block the content
thread doing some sort of synchronous operation (asm.js compile, sync xhr,
sync buffer decode, etc) would the user be able to hear the new
AudioBufferSourceNode while the content thread is stalled? Or would the
connection not materialize until the thread recovers, at which point the
entire buffer may have completed its (imaginary) playback? Can GC pauses
cause the same sort of problem and result in audio glitching?

Basically I think I'm suggesting there should be a 'concurrency' section
(though perhaps that's not the best term for these concerns) that describes
the particular behaviors that should/shouldn't be observable in a
conforming implementation. Maybe the list of conforming implementation
requirements is empty, in which case that section isn't as useful.

-kg

On Fri, Sep 13, 2013 at 3:34 AM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Sep 13, 2013 at 2:48 AM, Karl Tomlinson <
> karlt+public-audio@karlt.net> wrote:
>
>> "audioprocess events are only dispatched if the ScriptProcessorNode has
>> at least one input or one output connected."
>>
>
> I stand corrected!
>
> K. Gadd writes:
>>
>> > Doesn't that mean that ScriptProcessorNode can be used to observe GCs
>> > (measure how long it's been since the last onAudioProcess occurred on a
>> > disconnected ScriptProcessorNode)?
>>
>> the answer to this is still yes.
>>
>> If an AudioNode connected to the ScriptProcessorNode is deleted
>> because it has no references, then the ScriptProcessNode will stop
>> firing onaudioprocess at the time when the connected node is deleted.
>>
>
> I don't think so. In this case, the observable behavior that must be
> preserved is that the AudioNode is connected and the ScriptProcessorNode
> keeps dispatching onaudioprocess. Automatic removal of the AudioNode can
> only be done insofar as we preserve that observable behavior. In other
> words, the onaudioprocess event must keep firing.
>
> 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  *
> *
>