"From" + "to" problem - argument for "to" is not updated

  • Problem
  • Updated 3 years ago
  • Solved
Hi,
I just started to use soundmanager2, and think it's a great idea. However, I just stumbled over a problem that puzzles me: I have an audio file, from which I play sprites with the "from" and "to" arguments in play(). The user can click different buttons, and after the click I look up the relevant from and to times and pass them to SM2. Now the fragments are played, but as soon as a fragment that should be played, comes after the one previously played, it does not play. So basically, I can play fragment 10 to 1, but not 1 to 10. If I start with 5 I can play 5 again, or go down to 1, but never higher then the previous.

The problem is that the "to" argument is not updated in the failure cases. It just stays the same as specfied for the previous part. So because the duration is negative, nothing gets played. Also, the debugger shows multiple messages of the kind mySound: "to" time of xxxx reached. - one for each fragment play, where xxxx is the previous "to" argument. Happens both with Flash and HTML5 playback. (great debugging messages btw)

Edit: at the core, the problem seems to be similar to:

https://getsatisfaction.com/schillman...

What a coincidence! :) In fact, when I force

_onPositionItems = [];

after the "end" method of the _applyFromTo function, the playback errors disappear. The code is actually nicely readable, even if the variables are a little odd at the beginning. Any suggestions how I could achieve that less hacky?
Photo of mjstaffaM

mjstaffa

  • 4 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Scott

Scott, Official Rep

  • 3798 Posts
  • 245 Reply Likes
I'm going to need to follow up on this one, but it sounds like a bug. The from/to stuff is new and was introduced with a recent SM2 release, so I'm expecting there will be a few rough edges to fix.

If you have a simple test case that can reproduce the issue, that'll be helpful in troubleshooting. Thanks!
Photo of mjstaffaM

mjstaffa

  • 4 Posts
  • 0 Reply Likes
Hi Scott,
thanks for joining. I put a test case online:

http://narretz.de/test/

When you click the first one, you cannot get sound from the following. If you click on a different one, you can only get to the previous ones, never to the later ones (the numbers in the squares correspond to the sequences in the sound file).

However, the behaviour is also not consistent: when I click randomly, I sometimes can get sound on click (e.g. from 5), even after it stopped working properly. When that happens, the behaviour described in the first paragraph is repeated.

As I said, when I add

_onPositionItems = [];

to the end of the "end" function (line 2290) the problem disappears.
Photo of Scott

Scott, Official Rep

  • 3798 Posts
  • 245 Reply Likes
Thanks. I will try to look at this over the next few days and hope to sort it out.

I think someone else reported a similar issue with the "previous" vs. "later" behaviour, a little while back.
Photo of mjstaffaM

mjstaffa

  • 4 Posts
  • 0 Reply Likes
Thanks for looking into it!

I recently found another project using HTML 5 audio / flash fallback, focussing completely on sprite play:

https://github.com/zynga/jukebox

Maybe you can find some inspiration there. I just tried it---audio playback works flawless on iOS (iPad).
Photo of Scott

Scott, Official Rep

  • 3798 Posts
  • 245 Reply Likes
It may vary a bit by implementation (do they have a from/to feature?) - in my case, I just added that stuff recently and not all the bugs have been worked out yet. :)
Photo of Scott

Scott, Official Rep

  • 3798 Posts
  • 245 Reply Likes
Thanks for the report - I was able to reproduce, trace down the cause and fix this one. Turns out the first position (from/to) was still firing, and preventing your second range from playing because the first wasn't correctly removing itself.

So when you went to play 1000-2000 for example, the > 700 case was returning true and stopping playback.

The bug was that when stop() was called at 700, the "to" stuff was not being removed because it was comparing 700 to '700' (the string) in order to find the item to remove.

That has now been fixed and will be out with the next release.