WebAudio / web-audio-api

The Web Audio API v1.0, developed by the W3C Audio WG
https://webaudio.github.io/web-audio-api/
Other
1.05k stars 167 forks source link

ABSN looping vs start duration #1387

Closed rtoy closed 6 years ago

rtoy commented 7 years ago

In https://webaudio.github.io/web-audio-api/#looping-AudioBufferSourceNode, we say:

Setting the loop attribute to true causes playback of the region of the buffer defined by the endpoints loopStart and loopEnd to continue indefinitely, once any part of the looped region has been played. While loop remains true, looped playback will continue until stop() is called, or the scheduled stop time has been reached.

This kind of implies looping continues forever, independent of any specified duration used in start(), as mentioned in https://webaudio.github.io/web-audio-api/#dom-audiobuffersourcenode-start, which says that specifying duration is the same as calling stop(when + duration).

I think this needs to cleaned up a bit. It's causing some confusion on what the duration parameter to start() really means. See https://bugs.chromium.org/p/chromium/issues/detail?id=769634#c8

mr21 commented 7 years ago

Since I have discover that the OscillatorNode.start() can't schedule a stop (and so we have to schedule a .stop(when), I am wondering why is there a duration attribute for ABSN.start()?

This can produce a situation where somebody write a scheduler for ABSN only by using .start(when, 0, dur) and never .stop(when+dur), and after this is done, the scheduler is not naturally compatible with the OscillatorNode interface which has not .start(when, duration).

So why keeping two ways to schedule a stop on ABSN?

rtoy commented 7 years ago

Good question. I think this is an historical artifact. I think the duration parameter is to support playing of "grains" so you can specify a short section of an AudioBuffer to be played via start(when, offset, duration). This makes sense for an ABSN, but not an Oscilaltor.

But as mentioned in #421, it wasn't really clear what happens when looping is enabled. Hence, duration is defined to be equivalent to stop(when + duration). This makes it compatible with the non-looping case, and gives a well-defined meaning when looping is enabled.

mamekudz commented 7 years ago

Why not add an optional parameter "endSampleTime" to "start"-methode and change loop-definition to duration and/or endSampleTime? In this way the sound will stopped if endSampleTime or duration is reached. If duration is null or undefined and no endSampleTime is given, loop sound will played infinitive.

rtoy commented 7 years ago

I think it's way too late to consider changing it now; you'll break existing apps.

Maybe for the next version?

mdjp commented 7 years ago

1395 for V1 to address the unclear text regarding the duration parameter, but moving this issue to V.next

mamekudz commented 7 years ago

It would be nice if there will be an addional paramter in next w3c start-method-definition to define an endSampleTime. So, if duration is not given or extremly high, the sound will stop at this given sample time. This allow to use sound atlantes in browsers in the furture.

rtoy commented 6 years ago

I was going to update the title to reflect better what the request is here.

But I can't tell now. @mamekudz suggests adding an additional parameter endSampleTime, but from comments https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-333873653 and https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-334792214, I can't really tell what this is and how it really differs from duration.

mamekudz commented 6 years ago

Hi rtoy, it's about the end of sound condition. If the new definition should be based on the duration parameter, also if loop parameter is set to true, the additional paramter is very important. The additional parameter defines an additional condition to end the sound. If an endSampleTime is defined, the sound will stopped eigther the duration time is reached or the stop sample time (the time without loop, it is the real sample number inside the sound without loop calculations) was played. This is important if there are a sound atlantes where after the sound, which is currently played, an other sound follows. Every synthesiser uses sound atlantes to create sounds with multiple samples for different frequence areas and this feature is needed to implement browser synthesisers easyer. So a second "endSampleTime" parameter will be very helpfully. It is the simple synthesiser function: the user press the key (attack part), hold the key (loop part) and you don't know how long the user will press the key. If the key is released, the rest (release part) of the sound should be played, irrespective of the duration time defintion of the complete sound. Regards Meinolf

joeberkovitz commented 6 years ago

Let's leave this as the editorial bug on the clarity of the spec text which it was when @rtoy filed it. We don't see the need for these other changes; please file different issues.

mamekudz commented 6 years ago

Wow, debugging by changing the description. I think, you have not understand the problem.

rtoy commented 6 years ago

No, the actual bug that I filed was that the spec was not clear in a couple of places about what duration meant. It is you and others who piled on and morphed the issue into something else.

Now https://github.com/WebAudio/web-audio-api/issues/1387#issuecomment-342673667 just says the intent is to clarify the original spec text on just this original issue. All of the other points raised should be opened and handled in other issues.

I recommend you open a new issue stating clearly what you think is missing and the use cases for it. Possibly linking back to some of the discussion here if needed.

mdjp commented 6 years ago

Closed by #1395 file a new issue as requested