Audio pause problem in PhoneGap

Problem Description

I'm using a looping audio track, with an adjusted playback rate. When I pause and resume the track (on a Cordova export / PhoneGap build) the track continues from the paused point. But then all subsequent loops always start from that same paused point. For example, if I pause the track halfway through, every other loop (after resuming) will always begin at the halfway point.

Attach a Capx

https://dl.dropboxusercontent.com/u/78057629/AudioLoopPauseTest.capx

Description of Capx

This capx plays a simple countdown audio loop (e.g. 10... 9... 8... etc) with a reducing playback rate. It has a pause button, which sets timescale to 0 and audio to paused.

Steps to Reproduce Bug

• Step 1: Export the project using the Cordova export option
• Step 2: Zip exported files and upload to PhoneGap build
• Step 3: Install resulting app on Android device
• Step 4: Open app and allow it to play through a couple of loops, then press pause
• Step 5: Press resume and continue listening to hear each new loop (incorrectly) start from the point where the app was originally paused

Observed Result

After pausing and resuming the looped track, every subsequent loop always starts from the point where the app was paused.

Expected Result

Audio pause and resume to function normally (as in browser)

Affected Browsers

• Chrome: NO
• FireFox: NO
• Internet Explorer: NO

Operating System and Service Pack

Tested on PC using Win 8.1 & 10 - worked correctly, as expected

Tested on Android using HTC Desire (running Android 4.1.1) and Samsung Galaxy S5 (running Android 5.0) - did not work correctly (as explained in description)

Construct 2 Version ID

C2 version 212.2

Hello Friend,,,

The problem does not happen when you test your project in Construct 2?

The problem is in extrutura Phonegap,,,, also have had problems with audio in exports using Phonegap Compilation for Android by Intel XDK.

I mean the problem is with the Cordova + build type, it is no problem with Construct 2.

Has anyone from the Scirra team had an opportunity to test this issue yet?

Thanks

I don't know why you said it didn't happen in Chrome and referenced Cordova specifically - it reproduced on desktop Chrome for me where it's a lot easier to test.

There were a few problems here, and I've made the following fixes for the next beta which should help:

• [FIX] Audio: PlaybackTime expression now correctly takes in to account the playback rate (e.g. increasing slower if the playback rate is less than 1)
• [FIX] Audio: playback rate would reset to 1 (normal speed) after pause/resume or switching tab and coming back
• [FIX] Audio: could resume from the wrong location if paused when the playback rate is not 1

There is one catch though: it does not take in to account a changing playback rate, only a fixed playback rate. Since your demo keeps slowly changing the playback rate every tick it still won't work exactly. I'm not sure how to fix this; the Web Audio API does not provide a playback time, so we measure it ourselves from the start time, but if the playback rate has changed since the start time it's hard to work out where exactly it really is. We could try to compensate, but I don't think the JS timer will necessarily be synchronised with the audio playback clock. So I'm not sure we can fix this case I'm afraid.

Ashley, thank you for looking into this. And my apologies for missing the Chrome browser, I'm not sure how that slipped by. But I'm glad you were able to test the problem more easily, using Chrome.

Would it be possible to post the formula you're using for this. Maybe I can add something that will take the changing playback rate into account. Possibly by keeping a record of how often changes are made and/or how much the rate changes by. I'm using an exponential decay rate formula. So perhaps I could factor this in somehow, then set up my own version of the formula, using events.

When I initially came across the problem, I tried a work-around using the "Audio.PlaybackTime % Audio.Duration" formula. I think I was getting close to a solution by deducting the percentage change (of the playback rate) from the PlaybackTime. It wasn't quite right, but if I can keep a record of the amount it has changed by, I can possibly use that information within the formula.

Any help you can offer would be most welcome.

Thanks

Blacksmith - the formula for the current playback time is just (currentTime - startTime) * playbackRate. This of course assumes the same playback rate over that duration. The true formula would involve some kind of integration of the playback rate over time, but in practice that would probably still not work: integrating the playback rate over time in JS relies on JS timers, which are not synchronised with the audio playback clock, so they would end up drifting apart anyway. You could still try this in your events. Really what we need is some kind of playback time built in to the Web Audio API, which would need a spec change. I'll bring it up with spec authors and see what they say.

Thanks Ashley, I really appreciate the help.