W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2014

Re: Audio Workers - please review

From: Chris Wilson <cwilso@google.com>
Date: Sat, 13 Sep 2014 11:10:01 +0200
Message-ID: <CAJK2wqU3Sh84=aq0y6rvSAWOHxBFg8sXu5TmQQVzGfwdSraUYQ@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Joseph Berkovitz <joe@noteflight.com>, Ehsan Akhgari <ehsan@mozilla.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:14 UTC