Right. "Adding latency" that shifts the timeline of some nodes relative to others is clearly unacceptable. "Adding latency" that shifts the output of the entire graph to be a little later is clearly acceptable (though often undesirable). Here's a few situations where I think auto-parallelization has a good chance to win: 1) OfflineAudioContexts 2) When the inherent latency of system audio callbacks gives us time to synchronize multiple threads without adding latency. Depending on hardware, 3ms callback periods probably don't give us enough time, but 20ms could be enough time. 3) When the audio graph is so complex that single-threaded processing can't keep up with real time. Better to parallelize and add latency than underrun. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo.
Received on Friday, 12 September 2014 22:21:32 UTC