Re: Progression of currentTime in suspended state

Good catch.  Could you add this as an issue on the repo?
https://github.com/WebAudio/web-audio-api/issues.

On Fri, Dec 12, 2014 at 9:36 AM, Oleg Beletski <o.beletski@samsung.com>
wrote:

> Hello,
>
> I was exploring lately how to enable automatic suspend/resume
> functionality in chromium AudioContext implementation for the case if there
> are no active audio sources present in the graph. I practically got
> implementation working for the case similar to the one that is implemented
> by Gecko (
> https://github.com/WebAudio/web-audio-api/issues/317#issuecomment-42248626).
> Because of that work I am following what is happening in development of WEB
> Audio specification with introduction of suspend/resume/close states.
>
> I noticed couple of things in the specification that could be clarified
> better.
>
> 1. CurrentTime attribute of AudioContext
> <quote>
> currentTime of type double, readonly
> This is a time in seconds which starts at zero when the context is created
> and increases in real-time. All scheduled times are relative to it. This is
> not a "transport" time which can be started, paused, and re-positioned. It
> is always moving forward. A GarageBand-like timeline transport system can
> be very easily built on top of this (in JavaScript). This time corresponds
> to an ever-increasing hardware timestamp
> </quote>
>
> I understand that the latest draft of the specification actually enables
> us to pause and resume timeline of AudioContext and the transport timeline
> that is behind it. Do I understand correctly that currentTime is not
> progressing in suspended AudioContext? If that is the case, it would be
> good to reflect that in the description of the currentTime attribute.
>
>
> 2. suspend/resume methods of AudioContext
> <quote>
> "Suspends(resumes) the progression of time in the audio context"
> </quote>
>
> Would be good to use the same style of referencing to the timeline of
> AudioContext as in the other parts of the spec - "same time coordinate
> system as AudioContext's currentTime" to avoid potential confusion with the
> "transport" time.
>
>
> Implementation that I was working on is actually stopping that transport
> time of AudioDestination node while keeping AudioContext's currentTime ever
> increasing in the real time in way that is totally transparent to the users
> of WEB Audio API by switching to system timer.
>
> Best wishes,
> Oleg
> --
> Oleg Beletski
> Principal Engineer
> Samsung Electronics R&D, Finland, Espoo
> o.beletski@samsung.com
>
>
>
>