Fix performance issues with seeking while audio is playing

[todoroff]

When making calls to the seekTo method while the audio is playing, we were experiencing a issues with console errors and performance (to the point of the UI becoming completely unresponsive in the case of high-frequency seeking) because of unnecessary calls to start and pause inside that method.

Making the seekTo method async and awaiting the calls to pause and start inside solved the errors and the performance hit for low-frequency seeks (less than ~3 seeks per second) but wasn't good enough for higher-frequency seeking due to too much delay to resolve the promises.

We finally decided to remove those calls altogether, because they appear to be redundant. They were first introduced in #918, and supposedly solved an issue with backward seeking on MediaElement, which I wasn't able to replicate (tested with a 30 min long .ogg file).

[coveralls]

Coverage increased (+0.07%) to 80.0% when pulling 6c84519 on the-podcast-host:master into 590d9cc on katspaugh:master.

[sundayz]

It should probably be removed, but did you run the javascript profiler on your code to confirm that the calls to play() and pause() are slow?

It's been 6 years so the original issue with mediaelement is probably fixed and we can remove the play/pause calls

[todoroff]

It should probably be removed, but did you run the javascript profiler on your code to confirm that the calls to play() and pause() are slow?

It's been 6 years so the original issue with mediaelement is probably fixed and we can remove the play/pause calls

I haven't run a profiler.

What happens is that if you play and pause too fast one after the other, you get errors DOMException: The play() request was interrupted. After several of those, the entire browser bogs down until you hit pause.

If you do make sure play and pause run sequentially, meaning after each one is complete, and also awaiting each seekTo before shooting the next, there are no errors and browser responsiveness issues but you can't seek as fast as when the audio is not playing, which simply doesn't feel nice.

My benchmark was that in the last secnario you can make many more seeks while the audio isn't playing, compared to when it is playing, and assumed that it's because it's not making the play/pause calls and waiting for them to resolve inside.

[osheroff]

i'd definitely check this against a bunch of browsers and html-audio vs media-element combos. iOS/Safari tends towards "wildly different in behavior" vs firefox/chrome

[sundayz]

BTW if you want high performance you should be using WebAudio instead of MediaElement.

I assume you want to allow users to seek by dragging the cursor with the mouse during playback? With WebAudio you have more fine control over audio buffers etc which is needed for something like that.

[realies]

Works fine on Safari 13.1.2 (15609.3.5.1.3) over here.

[todoroff]

@osheroff Works on Safari.
@sundayz We need MediaElement for our usecase.

[thijstriemstra]

thanks @todoroff. I think we should give it a try; less is more. Can you add a changelog entry?