[Icecast-dev] Stagefright mediaplayer in Android

David Rönn Jansson david.ronn-jansson at readspeaker.com
Fri Jun 3 09:44:13 UTC 2016


Hi!
My name is David.
I'm having some problems with audio playback on Android and I was thinking
that maybe you have had the same or similar problem while streaming to
Android.

I ran across this issue: https://github.com/karlheyes/icecast-kh/issues/120
and that is exactly the problem I've been having. I don't know if this is a
official fork of Icecast or a personal fork, but I suspect the same problem
exists for the original Icecast.

Have you seen the same issue? Did you find a solution for it?

If you have seen this issue before, I posted on Androids issue tracker (
https://code.google.com/p/android/issues/detail?id=211838). If you are
interested, feel free to comment on that issue and say that you have the
same problem as well.

A little background information about my application:

I work with a application that produces audio. The way the application
works is that a request are done to a server where the request is handled
and then a redirect is done to point to where the audio can be found (and
then streamed back to the (often browser) where the initial request came
from).
Many users are browsing the web through mobiles these days and lately I've
discovered that there's some issues with Android's audio playback in their
browsers and I'm thinking it can be Stagefright that are the "bad"
component, or that I don't supply Stagefright with the correct information
which makes it behave bad.

Why I believe Stagefright is behaving bad is because the user-agent
"stagefright/1.2 (Linux;Android 4.4.2)" is used and seen in the access logs
of the servers, on to the problem:
It makes between 1 (which is what I expect) up to a couple of hundreds of
requests for the same audio file.
When I connect a android device through a proxy server to see the requests
made from the device, I can confirm this behavior and determine a pattern
on how the device is making the requests.
The requests is done in the following pattern:
Request 1: trying to determine where the audio file can be found.
Request 2: fetching the audio file, which is pointed out be the redirect.
(This request is successful, the whole audio file is transferred (at least
through the proxy).

If this is done once, everything works as expected, but when the pattern
repeats a number of times (1- hundreds) it causes the audio file to load
very slowly. I have no idea why this occurs, I have tested to give
different headers and http status codes back in the answer that contains
the location header (the redirect) without success.

I have tried to look at the source code for where Stagefright are fetching
the audio file, but I have not found the correct place.
Basically, I'm looking for a way to make Stagefright (android in general)
happy with the first response I'm giving it so it doesn't have to fetch the
same audio file 2 or more times in a row.

Many thanks!
Best regards,
--
David Rönn Jansson
System Developer

[image: ReadSpeaker - The Voice of the Web!] <http://www.readspeaker.com/>


[image: E:] E: david.ronn-jansson at readspeaker.com
[image: W:] W: www.readspeaker.com
[image: T:] T: +46 (0)18 60 44 41
[image: A:] A: Västa Ågatan 16, 9tr
753 09 Uppsala, Sweden
twitter.com/ReadSpeaker
Chamber of Commerce nr: 556747-2047
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast-dev/attachments/20160603/3d4400a4/attachment.html>


More information about the Icecast-dev mailing list