Re: Looping a specific number of times

I meant scheduling a stop(startTime+duration*loops).  That shouldn't be
driven from the main thread at all, should it?
On Mar 20, 2013 2:35 PM, "Ehsan Akhgari" <ehsan.akhgari@gmail.com> wrote:

> No, I'm not specifically talking about playback rate change.  The problem
> with relying on calling stop() is that stop() is driven off of the main
> thread, which makes it tricky to call it at the exact right time, which
> means that we will either cut the last iteration of the loop prematurely or
> we'll overplay from loopStart shortly before stop() manages to actually
> stop the playback.
>
> --
> Ehsan
> <http://ehsanakhgari.org/>
>
>
> On Wed, Mar 20, 2013 at 5:26 PM, Chris Wilson <cwilso@google.com> wrote:
>
>> I presume you mean in case playback rate is changed?  Otherwise you can
>> just call stop() for now +duration*loops.
>> On Mar 20, 2013 2:22 PM, "Ehsan Akhgari" <ehsan.akhgari@gmail.com> wrote:
>>
>>> There are use cases where you want to loop over an AudioBufferSourceNode
>>> a specific number of times.  I think that in the current spec, the only way
>>> to do that accurately would be to copy the same content enough number of
>>> times after in the buffer.  I think this could be a useful feature for us
>>> to support, and I think we can do that by adding a loopRounds (bikeshedding
>>> on the name to be done later ;) attribute to AudioBufferSourceNode, which
>>> basically stops the loop after loopRounds rounds if stop() is not called
>>> beforehand.
>>>
>>> What do you all think about this?
>>>
>>> Thanks!
>>> --
>>> Ehsan
>>> <http://ehsanakhgari.org/>
>>>
>>
>