Re: Looping a specific number of times

It's not, but wouldn't that cause potential glitches resulting from
rounding errors?

--
Ehsan
<http://ehsanakhgari.org/>


On Wed, Mar 20, 2013 at 5:58 PM, Chris Wilson <cwilso@google.com> wrote:

> 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/>
>>>>
>>>
>>