Android playback has too much delay

[multidynamic]

Matthew Adler created an issue 2014-12-10
The android client stream playback has a delay that is too long.
Also, obtain metadata from the stream at start and during playback.
Ten hours budgeted to this; will not fix when reaching 10 hr mark.

❌ A major issue

Halsey Burgund REPO OWNER 2014-12-10
The delay in playback of the stream is most likely related to device buffering as the streams themselves are typically created in 3-5 seconds on the server. There is a known issue with the inability to control buffer times with the standard Android MediaPlayer:
https://code.google.com/p/android/issues/detail?id=29870
I guess the buffer is set at a certain size in bits, so for lower bitrate streams, it can be really long whereas higher bitrate streams it can be quite short. I have done some experiments that corroborate this, but clearly we don't want to control the buffer time by changing the stream bitrate(!)

Matthew Adler REPORTER 2014-12-10
Thanks for your feedback Halsey, I did not notice the issue with the build as is. Perhaps because the bitrate is high enough to quickly fill the buffer you mention.

Halsey Burgund REPO OWNER 2014-12-10
Yeah, I'm not entirely sure...it's been one of those issues that sometimes is excruciating and other times isn't too bad and I really haven't had the time to fully investigate. I've been following that bug just to keep tabs on it and keep hoping it will be fixed as having a bit more control would be really nice.
Rob Knapen, the original developer, has done research on this and discovered something called ExoPlayer, that apparently gives much more flexibility, but is more work to implement. Perhaps you're familiar with it?
http://developer.android.com/guide/topics/media/exoplayer.html
Not sure what makes the most sense, but keep us posted on what you think.
PS-nice to meet you and great to have you on-board! We should connect on chat as well as that'll speed other communications as needed. I'm [email protected] on gchat...

eosrei 2014-12-10
Anyway. I just tested this today in the sculpture garden. I'm staring at my phone wondering why it is silent for 10 seconds. Nothing. No GUI updates. No audio. It could be buffering and (cause I know how this works) it could be that my phone hasn't decided to send a GPS location to the server so I'm listening to nothing. Which is entirely a separate issue than this.

Matthew Adler REPORTER 2014-12-10
Did the play icon switch to the pause icon? Maybe GPS is the limitation, i'll check into that.
Thanks

eosrei 2014-12-10
Yep, pause icon shown.

[multidynamic]

I wasn't able to speed it up with my 10 hour investigation, but I did find exoPlayer does work and is quick: like 1.8 seconds versus a comparable 6 seconds. Unfortunately exoPlayer integration would benefit only newer devices: that is devices running Android 4.1 and later.

The other 4 seconds are likely due to overhead with the usage of async tasks, which are not appropriate for this implementation.

[13rac1]

@multidynamic What can we do about the other four secs of async? Would it be better left to fix with #26 (long in the future)?

[multidynamic]

@eosrei If AsyncTasks do not need to update UI elements then a Thread would be better suited. Also instead of broadcasting intents to all processes, instead consider using the LocalBroadcastManager.

But yes, an implementation of Issue #26 will reduce delay by allowing the client to render audio as gps position is detected instead of sending and waiting for a stream modification is complete. It will fix issues related to pausing and in general give the client more flexibility.