IE9 non-sprite audio stops playing (howler.js 1.0 and 1.1) about howler.js HOT 18 CLOSED

I was able to improve things by reverting the change from issue #15 (so that non-sprite HTML5 audio is paused after it completes), and instead setting the playback position to a hard-coded 0 if the audio is not a sprite, in the play function around line 314 (in 1.1). so going from this:

  // determine where to start playing from
  var pos = (sprite) ? self._sprite[sprite][0] / 1000 : self._pos,

to this:

  // determine where to start playing from
  var pos = (sprite) ? self._sprite[sprite][0] / 1000 : 0,

(self._pos can end up being non-zero values at this point in the code, which does not seem like what you'd want...)

After this change the audio doesn't completely cut out like before, although it still is intermittent, dropping some audio.

This is because under IE9, if howler.js can't find an inactive node to use, in the _inactiveNode function (around line 860-870 in 1.1), then the rest of that function that creates a new node does not work, so that audio does not play.

from howler.js.

I realized that what I did in the code in my previous comment breaks pausing and then playing from where you paused. (Should have known there was a reason things weren't hard-coded there.) So instead you would just reset the playback position to 0 after the audio finished playing, around line 337 in 1.1, like so:

      // end the track if it is HTML audio
      if (!self._webAudio) {
        self.pause(data.id, data.timer);
        // reset playback position to zero for non-sprite audio
        if (!sprite) {
            self._pos = 0;
        }
      }

(I had tried this before, but was getting clipped audio in IE9, but that may be related to the problem mentioned at the end of the previous comment.)

from howler.js.

I realized that howler.js gives you the option to set the starting playback position for an audio clip to a non-zero value. (Around line 156 in 1.1) So that value should be used instead of 0 when resetting the playback position (as in the previous comment). But currently I don't think that this starting position value is being stored so that you can access it later like that. (Also for the stop function, around line 472 in 1.1)

Just a thought... instead of storing the custom start value, would it make sense to just treat all audio as a sprite internally? So if an audio track was not set up as a sprite by the user, automatically set it up as the simplest sprite possible: one that has a single audio clip that starts at zero (or a custom start point set by the user) and ends at the end of the audio clip. That might simplify things since you could then treat everything as a sprite. Might not be a good idea, just thinking out loud... You'd want to test it out with IE9 first, since it does not do well with sprites, but maybe it could handle this simplest of sprites.

from howler.js.

Currently doing some testing with this, thanks for the detailed report.

from howler.js.

I just pushed a significant update to 1.1.0 that uses your idea of auto-defining a sprite for sounds that don't have one user-defined. I also did quite a bit of refactoring in other areas to fix some other issues that I came across. This should now fix the IE9 issue, but please reopen this if you find any other issues.

I've got a few more things on my list to take care of for 1.1.0, but hope to merge it to master sometime next week.

from howler.js.

Nice! Thanks for working on this, and glad you liked the auto-defining sprite idea.

I got a chance to test it again today, and unfortunately it was not working well on either Firefox or IE9. It was dropping HTML5 audio clips because the playback position wasn't getting reset to zero when the clips finished. I just sent a pull request that fixes that problem. With this change everything works great on Firefox.

However, I'm still seeing the same issues with IE9. I did some tests and at first all works well, but after playing enough audio clips, some of the sounds start getting dropped. What's happening is that when it can find an inactive node (using the _inactiveNode function at line 360) it plays fine. When it can't find an inactive node to use, at first it does fine adding new nodes, but soon enough this stops working, and it gets only as far as:

    newNode.addEventListener('loadedmetadata', function() {
      callback(newNode);
    });

on line 888. It seems that this event listener stops working, so the callback is not firing, so the audio is not played.

I haven't noticed any other glitches with the 1.1 branch though.

from howler.js.

Could you setup a jsfiddle of how you are getting this to happen on IE9? I'm not seeing the same thing. Are you just playing the sounds over and over, or are you playing many all at the same time?

from howler.js.

I'm just playing one sound over and over. I haven't used jsfiddle, but I'll see if I can put something up there. Here's the webpage I've been using to test it if that helps. I added console.log messages to see what's going on.
http://twinnote.org/labs/test-page/

I use the keyboard to play the same note over and over, but you can also see the problem when playing one of the melodies.

Just a heads-up that sometimes the UI on this page does not load at first in IE9. (It gets stuck at "loading audio".) Sometimes I have to reload the page, or click "scales" then one of the scale buttons, then "play audio" to get it up and running. (Something else I need to work on...)

from howler.js.

Alright, here's a minimal example on jsfiddle. I got it to work in Firefox on jsfiddle, but not in IE9. You can at least see what I'm doing though. Hope that helps!
http://jsfiddle.net/eWBYK/6/

Note: updated, forgot to save the most recent version (6) on jsfiddle. Also, this is using my forked version of howler.js with my most recent pull request in it.

from howler.js.

Just wanted to say that I realize this may be a case of "IE9 just doesn't handle HTML5 audio that well." Especially since it starts out working, but then stops, that suggests that this may just be IE9's problem.

In case it is helpful, here's what I did for my particular site, that worked for IE9, before I started using howler.js. Instead of trying to load the audio node right before playing it, I would preload nodes for each sound when the page was loaded, and then right after a node was played, I would create a second node for the same sound. Then that second node would be used when that sound was played again (and then a third node would be created, etc.). Basically, instead of load then play, I would play then load (for the next play). This avoided any IE9 lag from trying to load the audio nodes right before playing them, since they would already be loaded.

Since I knew three nodes for each sound were enough for my site and sounds, after three nodes for a given sound were created, I would just rotate through those 3 nodes as the sound was played. So the nodes were never destroyed after they were created. But that approach is not easily generalizable to all use cases...

Anyway, howler.js has a much more robust way of handling this, but FWIW I thought I would pass on what I was doing before, in case it's any help. Thanks again!

from howler.js.

Are you still having this issue with the latest version of 1.1.0?

from howler.js.

I just tried the most recent version in IE9 and it's still dropping audio clips. I got my JS fiddle demo to work in IE9 by pasting in the most recent howler.js code:
http://jsfiddle.net/eWBYK/9/

If you play a few different notes, playing them more than once each, soon enough it starts dropping some of the notes. Firefox still works great. Not sure it's worth holding up the 1.1 release for an IE9 problem though.

from howler.js.

Does this seem improved at all to you? http://jsfiddle.net/NG7GE/2/

from howler.js.

It seems the same as far as I can tell. After playing enough notes, and playing each note several times in a row, it gets to a point where most notes after they play once they will not play again until about 3 seconds later, which is the duration of the audio files.

So it seems like new nodes aren't being created in IE9 after a certain point, as described in my comment above:
#25 (comment)

from howler.js.

I'm afraid we might just be seeing a limitation of IE9. Out of curiosity, I updated this fiddle (http://jsfiddle.net/NG7GE/5/) to preload 5 extra nodes for each sound, and it appears to make it worse.

from howler.js.

I think you're probably right. (That's interesting and odd the way preloading made it worse...)

from howler.js.

That may also just be because the machine I was testing IE9 on is about 7-8 years old, but at the same time it works fine on that computer with the other browsers.

from howler.js.

I have recently used Howler for one of my projects, and I must say that it's a neat and nifty little JS. I am posting a comment here because I am facing a similar issue that's mentioned in this thread; but with IE10 and IE11. My project uses audio sprites and version 1.1.26 of Howler. Just wanted to know if this issue still persists with higher versions of IE as well.

from howler.js.