Event queue is not processed when _playLock is false

[tobspr]

When a html5 sound has not been unlocked yet, any calls to e.g. volume are queued. This only happens when reusing a sound id.

https://github.com/goldfire/howler.js/blob/master/src/howler.core.js#L1206

        // If the sound hasn't loaded, add it to the load queue to change volume when capable.
        if (self._state !== 'loaded'|| self._playLock) {
          self._queue.push({
            event: 'volume',
            action: function() {
              self.volume.apply(self, args);
            }
          });

However, this queue is never processed after the sound has been unlocked:

This leads to calls like .volume(), .play() etc not being executed if they are issued before the sound has been unlocked.

I didn't dig too deep in the sources, but I guess after the sound has been unlocked the queue would have to get re-processed.

[inear]

Also seek() without parameters to get time gets queued up, which is not very useful. It feels like a memory leak that it can fill up this queue with potentially endless actions, when only the latest of each type (per sound instance) is useful. I realised this after finding a queue with 20000 items, just because my playerUI was listening for the sound time without user interaction for a while. Also takes lot's of time to run seek(time) many times when user finally click the play-button. All this can be worked-around, checking the playLock flag, but it's not optimal to do outside the library.

[filpez]

When fade() is queued any instruction called after it is not executed.

This seems to be due to fade() not emiting any event, which would trigger the next queue task to be processed. I don't know if other instructions are also missing this emission, but I hope this serves a starting point.