- From: Chris Rogers <crogers@google.com>
- Date: Mon, 10 Dec 2012 17:27:19 -0800
- To: robert@ocallahan.org
- Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>, public-audio@w3.org
- Message-ID: <CA+EzO0krqqmx80WP2g7aq80AuPy5d8RUas1srO=stfK=xQsMoA@mail.gmail.com>
On Mon, Dec 10, 2012 at 4:51 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Tue, Dec 11, 2012 at 11:55 AM, Chris Rogers <crogers@google.com> wrote: > >> I have never seen any desktop audio applications go to great lengths, for >> example, to ensure that the level meters of different channels of a mixing >> board were all sampled from the same "audio render quantum". It's just not >> considered that much of an issue. >> > > OK, but we aren't building a desktop audio app, we're building an API that > thousands or millions of relatively unsophisticated developers will use in > ways we can't anticipate. We're also doing it in a context where unexpected > delay on the UI thread is an omnipresent threat. As such, given we can > provide a consistent snapshot relatively easily, it seems prudent to do so. > (For example, one way to implement the snapshot would be to just snapshot > the currentTime for an AudioContext and then have every > AudioParam.computedValue refer to that currentTime and compute its value > based on that.) > I can see how an AudioParam could keep a record for .computedValue for the last N "rendering quantums", so it could look back in time to the .computedValue corresponding to the snapshot of .currentTime you're suggesting. But we can't go back an arbitrary amount of time, since we don't have infinite storage. This value is computed based on timeline values and also audio-rate signals (from other AudioNodes) connected to it. So we don't necessarily have all the information we need to compute this value on-the-fly arbitrarily backwards in time. Perhaps there is a clever technique, and I'd have to understand more specific details of exactly how you'd approach it. But in any case, I would not like any solution which would worsen the normal average update rate of these parameters if animated at 60fps in requestAnimationFrame(). In other words, if a solution to synchronize these values to a snapshot caused the average performance of the animation to appear more choppy, then that seems bad. This particular feature (exposing .computedValue to JS) is probably not among the most important to have, so maybe it's not even worth worrying about if we decide not to do it. Chris > > Rob > -- > Jesus called them together and said, “You know that the rulers of the > Gentiles lord it over them, and their high officials exercise authority > over them. Not so with you. Instead, whoever wants to become great among > you must be your servant, and whoever wants to be first must be your > slave — just as the Son of Man did not come to be served, but to serve, > and to give his life as a ransom for many.” [Matthew 20:25-28] > >
Received on Tuesday, 11 December 2012 01:27:47 UTC