If you (and Joe) are saying you want to keep the possibility of utilizing parallelization when it would not cause appreciable differences in the rendering (i.e. it's possible it would add to the total latency, just as an implementation might choose to avoid underruns by increasing latency) and wouldn't be observable in any way other than the overall system latency, then I don't have a problem with that. For example, in offline audio context, an implementation could spawn as many threads as it wants to, as long as the final rendering is the same. If you can work ahead, you could utilize extra threads in a subgraph in a live context too. As long as it would only add uniform latency to the entire graph (or be a developer choice). On Sat, Sep 13, 2014 at 12:21 AM, Robert O'Callahan <robert@ocallahan.org> wrote: > And no, I'm not expecting this to be implemented anytime soon. But if it's > inexpensive to leave the door open for parallelization, it's responsible to > do so. > > 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 Saturday, 13 September 2014 09:10:28 UTC