Audio playback resumes from pause on its own

[multidynamic]

Matthew Adler created an issue 2014-12-10
To repro:

1. Begin audio playback
2. Pause audio
3. Put Perspectives in background via a notification
4. Press back in notified application
5. Perspectives should return to view on its own (that's okay)
6. Observe audio resuming (as if user pressed play button)

This is probably a difference in handling Resume from paused activity versus a created one..

[multidynamic]

Maybe related to #18

[hburgund]

A general crucial comment about pausing the audio stream (not sure if this is the best issue for this, so feel free to move as needed): Latency is extremely important for functionality of the app as no one wants to hear audio from where they were minutes ago; they want to hear audio from as close to their present location as possible. There will always be some buffering to avoid stuttering and cut-outs (hopefully some day this buffering amount will be controllable), but "pausing" has to be done right in order to not vastly increase latency.

I think what we tried to do most recently in Android was essentially to mute the audio when the pause button was pressed rather than actually pausing it. If we paused it, and then un-paused 2 minutes later, we would have introduced 2 more minutes of latency into the stream, which is unacceptable. But different media players handle this differently, so I'm not sure of the current behavior. Of course, muting the audio has other problems, like wasting bandwidth etc.

Perhaps the stream should be stopped and then when un-paused, it re-connects somehow at the "present" spot? This would take time and would require the app to send heartbeat API requests to keep the stream alive on the server, but might still be better than the alternatives. I'm not sure what the best solution is, but want to make sure we consider this as if handled poorly, it can ruin the experience.

Any ideas or updates on what is actually happening currently?

[multidynamic]

Muting does reduce the latency when resuming but its biggest side-effect is that user's may miss listening to assets while muted. As you suggest, a stop-gap solution for that side-effect would be to modify the stream when muting so that assets are not consumed.

As for the main issue, I have not investigated it since reporting, but I suspect the mute state may be overtaken by handling of the app's activity resuming. A careful examination of the factors that affect this mute state should reveal the problem here.

[13rac1]

We need to correct the issue described by Matt: Stopped/paused audio must stay that way.