- From: <bugzilla@jessica.w3.org>
- Date: Wed, 04 Sep 2013 22:57:25 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23007 --- Comment #15 from Chris Wilson <cwilso@gmail.com> --- (In reply to comment #13) > > > Consider what should happen when you have a buffer of 1s, and pass in 2s as > > > the duration with loop==false, then call start() and in about 1.5s, you set > > > loop=true. Should the implementation play the buffer for the first second, > > > then produce silence for half a second, and then jump back somewhere in the > > > middle of the buffer and start playing back? That sound insane to me, and > > > I'd be quite strongly opposed to that. > > > > I would expect the onended would have fired and the memory potentially > > reclaimed already, so no, I wouldn't expect that. > > This directly contradicts with your earlier suggestion: > > "The duration certainly CAN be longer than the buffer (length-offset) in the > non-looping case - it will just be silent after it runs out of bits." > > You should pick one behavior or the other, as they're contradictory. No, I don't believe that they are, as I didn't mean that latter literally; I meant it in response to your implicit suggestion this was an error (invalid). I see hitting the end of the buffer and the end of playback, according to the current settings: 1) single-shot playback, bufferlength is reached, or 2) single-shot playback, duration is reached to cause the buffersource to no longer be active, and as per design constraints, it cannot be "revived". In old parlance, it's FINISHED_STATE. It's done. I would likely expect onEnded to fire, for example, not after duration, but after playback is done. > Well, loopStart and loopEnd are both attributes on the object, what should > the following code observe? > > console.log(node.loopEnd); // 0 > node.loopStart = 10; > console.log(node.loopEnd); // ??? > > It is very weird to have assinging to loopStart suddenly change loopEnd. > > Your suggestion would be OK if these were just internal state, but > unfortunately they're not. (And yes, this is bad API design, a better API > would be something like: |void loop(double loopStart, optional double > loopEnd);| and then we wouldn't have this problem. :( Huh? I would expect the log above to issue 0 0 loopEnd doesn't get assigned by the assignment of loopStart - it's an input attribute, not a reflection of internal state. Otherwise that first log shouldn't show zero either - it should show bufferLength, since if loopStart is unassigned, it will play through as if loopEnd were set to the length of the buffer (i.e, loop the entire buffer). I would not, in short, expect assigning loopStart to change loopEnd. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 4 September 2013 22:57:26 UTC