Audio cache strategies

by David Given » Tue, 02 Sep 2008 06:05:28 GMT

Sponsored Links
 I'm currently working on a custom audio player app for an online music
site. It has the following main requirements:

a) I need to be able to play music without waiting for it to download.

b) I wish to cache the music locally so that the user's favourite tracks
don't need to be downloaded again.

Currently my strategy is to download the files locally and discard the
oldest ones when I need more space, keeping all the metadata in an
associated SQLite database; but this approach is rather problematic and
very brittle due to having to keep the database and the files in sync,
issues with ensuring that a file isn't removed when something else is
wanting to use it, etc. Not the least of which is that caching entire
files means using up rather a lot of disk space --- some of my music
files can be 15MB+.

Also, MediaPlayer appears to be very picky as to what it plays from: it
insists on playing from a file, or at least a file descriptor, and when
you start playing it measures the length of the file and won't play past
the end point, which is a bit of a problem if you haven't finished
writing it yet. At least 0.9 has fixed the issue where getDuration()
used to calculate the duration of the media based on the physical file

Can anyone suggest any alternative approaches to doing this? What I'd
*really* like to do is to be able to store my entire cache in a single
huge fixed-size file, optionally on the SD card, and stream fragments
directly to MediaPlayer; but I don't think that's possible and Java
would probably be too slow anyway. Alternatively, a block-level cacheing
HTTP proxy would do almost as well. Does Android have one?

€€  €€€€€  €€€€€
"All power corrupts, but we need electricity." --- Diana Wynne Jones,
_Archer's Goon_

Audio cache strategies

by Josh Guilfoyle » Tue, 02 Sep 2008 23:23:07 GMT

 his is exactly the sort of problems my application (http:// must contend with, and unfortunately I have came
to the conclusion that for 1.0, Android will simply not be able to
support our type of application.

Their current official recommendation is to work around this by
constructing your own local HTTP server to both stream and cache
("tee") the proxied content. Even ignoring the enormous overhead this
introduces it still won't work. There are yet more problems lurking
in the MediaPlayer which prevent applications which need information
about the buffering heuristics built into the system. For instance,
the MediaPlayer.OnBufferingUpdateListener class can supposedly be used
to detect when the buffer is full (playback has begun), when it
becomes empty again (playback chokes), and everywhere in between so
the application using it can provide essential feedback to the user.

I constructed simple tests which clearly demonstrate that
onBufferUpdate is fired with entirely different metrics that I cannot
understand, but clearly do not represent buffer fill percentage. In
my tests, playback started anywhere from 5% to 25% "buffer fill
percentage", though it seemed more like the buffer fill percentage was
total file progress (but not quite). Likewise, the buffer fill
percentage never declines, so it isn't possible to detect when a song

Once open sourced, I will be working to fix the broken MediaPlayer so
hopefully I can target a 1.1 release without waiting on Google to fix
this set of classes. Would've been really nice to have a heads up
that maybe the MediaPlayer brokenness from back in M5 was not a top
priority and was unlikely to make it into 1.0.

On Sep 1, 3:05 pm, David Given <[EMAIL PROTECTED]> wrote:

Sponsored Links

Audio cache strategies

by David Given » Tue, 02 Sep 2008 23:44:45 GMT


Oh, dear.


Is that on m5 or 0.9? I know there are a lot of bugs that have been
fixed in 0.9 (and still some to go...).

Also, how well does MediaPlayer work streaming off the real internet? Is
the buffering effective?

David Given


Audio cache strategies

by Josh Guilfoyle » Wed, 03 Sep 2008 00:57:18 GMT

 These tests were against 0.9, and I have complained loudly about it
with any Google engineer that would listen.  The outlook looks bleak
to get these fixes in for 1.0.

Also, in my tests, the MediaPlayer buffers poorly.  It seems to take 2
- 5 seconds to even gear up and make a connection for some reason, and
then it seems to buffer more than is necessary in certain
circumstances.  I'd like to load a simple test up on the HTC Vogue and
see what more I can learn about how 0.9 behaves on real hardware.


Audio cache strategies

by David Given » Wed, 03 Sep 2008 07:26:50 GMT



Well, with much trepidation I've ripped out all my cacheing code and am
now using pure streaming --- and it all works far better! I'm not seeing
any of the buffering problems, and it all seems to be quite snappy, even
when seeking beyond the buffer limits.

However, I completely agree about the onBufferUpdate() parameter ---
it's completely useless. I think it's showing me the high-water-mark of
the buffer. Without the matching low-water-mark, I can't doing anything
useful with it. onSeekComplete() seems to be a bit questionable, too, as
when I get events seems completely unrelated to whether it's actually
finished buffering or not.

I also notice that streaming Ogg Vorbis files fails with, yes, another
undocumented error code --- is this known to not work?

€€  €€€€€  €€€€€
"All power corrupts, but we need electricity." --- Diana Wynne Jones,
_Archer's Goon_

Other Threads

1. plz help with camera application from my application

hi !! I am stuck with this . I just want to call the built-in camera
app when i click a button in my app preview. plz share the source code
if anyone has done it.


2. plz help with sdcard image file and push command not working!!

thanks john. how to enter images in the gallery ???


Communications Engineering Student,
NUST, Pakistan.


3. selector is not working! argh....

4. Anim folder not showing in eclipse

5. selector is not working! argh....

6. Using Picasa Web Albums Data API in Android

7. Route between two GeoPoints/ lat-lon pairs