Linking with everyplay.framework will interfere with AVAudioPlayer

[NKJasonHorsburgh]

It appears that there are issues when trying to play AVAudioPlayer instances when everyplay.framework is linked into the application.

In our application we change background music by fading out to 0 volume over a short period of time and releasing the old AudioPlayer instance. We then load the new source into a new AVAudioPlayer and fade in back to full volume. When the new source is played there is a high chance that:

• you will here a 'crack' sound and the track will continue normally, fading in from 0
• or that the new track will start playing at full volume for a split second and then will either appear to stop playing or will be playing at a very low volume.

If I don't link against the framework then the new audio track will play correctly from the correct starting volume. I've attached delegates to the audio session and player and there are no errors. The audio player also returns that it's volume is at the volume we're attempting to set it at, even if the track appears silent or at low volume. No direct calls to the Everyplay code from the application is required (I commented out everything I had) to trigger the bug.

Tested devices: iPod 5th Gen iOS 7.0.4 iPad Air iOS 8.3

Tested SDKs: 1.9.7 1.9.8

Music Track details: we swap between 3 different tracks 1 x 22,050 sample rate single channel mp3 track 2 x 44,100 sample rate double channel mp3 tracks

[aet]

Hi, can you post a testcase somewhere?

We've seen the volume fade issue happening with at least some pre-ios8 devices and had to add some workarounds for it, it's an internal iOS issue where sometimes the volume commands just get blocked/timed out when communicating towards mediaserverd. Sometimes just setting the volume again can help

[NKJasonHorsburgh]

Hi, I've tried with both setting the volume on the AudioPlayer only during the fade and setting it every frame and both generate the issue. I'll see what I can do about getting a test case together but I'm not sure how easy it will be to isolate from our codebase.

[dannyNK]

Aside from changing tracks, just changing volume on a single track is also prone to issues. When fading in a track, the fade will complete, then suddenly drop to a fraction of the volume, despite setting that volume every frame. It appears as though there is some optimisation around setting the volume in everyplay that is not working correctly.

Every 60 frames I added a small offset to the volume which we pass to the AVAudioPlayer which caused the actual volume to change to what we are setting it to every frame. This still left a short period of where it dropped back to the mid-fade volume though. Currently we are adding a randomised value to our volume and set it every frame to reduce (but not eliminate) the sudden incorrect volume change.

It is as though everyplay is polling for the current volume every 1 second for example, which is picking up the volume mid-fade, but then every frame it is polling for a change in the volume. When it registers that the volume is no longer changing, it locks in the volume grabbed from the 1 second poll (the mid-fade volume). I doubt this is what is happening, but its the best way i can think of to describe the issue.

[aet]

We're restoring our old AVAudioPlayer implementation within the next release to workaround volume fade and iOS 9 compatibility issues, this should be available by next monday the latest

[dannyNK]

Thanks for the heads up.

[aet]

2.0.1 sdk update is now out, along with iphone 6s specific fixes, thanks!