- From: Chris Rogers <crogers@google.com>
- Date: Thu, 22 Mar 2012 12:44:52 -0700
- To: robert@ocallahan.org
- Cc: olivier Thereaux <olivier.thereaux@bbc.co.uk>, public-audio@w3.org, jussi.kalliokoski@gmail.com
- Message-ID: <CA+EzO0kLO0GCEG7WP2v0f+GPN7ikCbhf+FW6AcANUtZTEskrEA@mail.gmail.com>
On Wed, Mar 21, 2012 at 9:56 PM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Wed, Mar 21, 2012 at 5:29 AM, olivier Thereaux < > olivier.thereaux@bbc.co.uk> wrote: > >> Could you have a look at it and tell me: >> * Whether the page correctly records the conversation and the issue (and >> whether I've missed anything), and >> * Whether the discussion during the teleconference on March 5th, where >> Chris stated there was sufficient control in the API, can be considered a >> suitable resolution to the issue >> ? >> >> > > It sounds like Chris is saying that you can pause a subgraph by pausing > all its inputs. > For dealing with arbitrary parts of the graph (sub-graphs or sub-mixes) one technique is to control the .gain parameter on an AudioGainNode which controls the overall volume for that part of the graph. The gain/volume transition can be made suddenly or slowly faded out at precise times. Another technique is to simply stop scheduling any new "notes" from playing in AudioBufferSourceNodes, and by stopping any currently playing notes by calling the noteOff() method. Sometimes, it will be a good idea to schedule the noteOff() to not happen immediately, but to wait for the exact time that a loop reaches its end. > > It seems to me that wouldn't be satisfactory. First of all, there are no > guarantees that explicitly pausing each input will pause them all at > exactly the same moment, so pausing and resuming would break > synchronization. AudioBufferSourceNodes can be scheduled to happen at exact times. So their start and end times can be given precisely and will be synchronized. > Secondly, this approach doesn't pause filter processing, and for many > applications pausing the inputs (and treating them as silence, which I > think is what Web Audio would do) would give different results from pausing > the subgraph. For example, if you have a filter producing echoes, you will > hear an echo after you pause the inputs, which is not what you want if you > wanted to pause the subgraph. It's interesting to discuss this type of scenario in more detail. In a simple case let's consider a simple source feeding into an "echo" or "reverb" efffect: source -> reverb -> destination If the source is playing for a while with the echo/reverb effect, then paused for a little while, then later resumed let's see what the possible behaviors could be: WHEN THE SOURCE IS PAUSED 1. When paused all sound stops immediately. 2. When paused the sound from the source stops immediately, but the echo (tail of the reverb) continues to play until it dies down completely. Either (1) or (2) may be the desired behavior. As an example of (2) please see ToneCraft in Chrome or Safari nightly (when playback is paused with the space bar): http://labs.dinahmoe.com/ToneCraft/# WHEN THE SOURCE IS RESUMED When paused according to (1) 1a. The echo/reverb is heard from old (before pausing) sounds played by the source, layered on top of echo/reverb from the new (resumed) sounds from the source. 1b. The echo/reverb is heard only from the new (resumed) sounds from the source. When paused according to (2) 2a. The echo/reverb is heard from the current (resumed) source layered on top of the uninterrupted/continuous previous echo/reverb 1a is considered to be anomalous behavior in musical applications since it abruptly re-introduces old/stale echo/reverb state into the rendered audio stream. It can be caused by a filter (echo/reverb in this case) not having its state reset properly at the moment of "pausing" for case (1). 1b and 2a would be the desired behavior respectively for pause types (1) and (2). > Thirdly, having to explicitly pause each input is not very convenient. If > an app developer wants to be able to pause the output of some complicated > graph, they have to keep track of all the active inputs themselves. > I'm going to disagree with you on this point. In many cases "pausing" can be as simple as adjusting a sub-mix gain, or simply allowing existing "one-shot" sounds to finish and stop scheduling new notes. In other cases for continuously playing/looping sounds, it's not really that difficult to keep track of the relevant active sources. Chris > > ProcessedMediaStreams does allow pausing of subgraphs. > > Rob > -- > “You have heard that it was said, ‘Love your neighbor and hate your > enemy.’ But I tell you, love your enemies and pray for those who persecute > you, that you may be children of your Father in heaven. ... If you love > those who love you, what reward will you get? Are not even the tax > collectors doing that? And if you greet only your own people, what are you > doing more than others?" [Matthew 5:43-47] > >
Received on Thursday, 22 March 2012 19:45:22 UTC