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. Hot reqvirement in hyderabad---mindtree

HI send ur resume i have one reqvirement in the android one of the big
mnc company
so u send ur resume who are locate in hyderadad


2. Global Media firm in NYC (new MOBILE APP R&D Team)

Great job opportunity for:

MOBILE APPLICATION DEVELOPERS (Developing Consumer Apps for Android,
iphone, ipad, and Blackberry)

Global Media firm in NYC has Mobile Applications R&D team looking to
build NYC presence!

Building an elite team of Mobile Application Developers for Android,
iphone, ipad, and Blackberry devices.

This high profile, highly funded company has a successful Mobile
presence already that delivers apps to over 600,000 users/day.  They
are creating new revenue generating products and now looking to expand
Consumer Applications and channels for Mobile devices.  Looking for
experience building Commercial Mobile Apps.  Should have experience
successfully creating and deploying mobile apps commercially.
Development is FPLC and front to back.  Will build real time services
that deliver data as well as UI and device development.

While this team will build and deploy apps across multiple platforms/
devices, there is a definitive need for Android exerience.

Developers must be proficient with standard Java development tools,
including ADT plugin, JUnit, and popular IDE such as Eclipse.
Proficiency with open source frameworks or third-party libraries
specifically required for Android applications.  You will design,
develop and test applications from the ground up working with outside
data sources and API's.  You will develop and deploy Android OS 1.6+
based applications using Java.  Experience with multiple mobile
platforms (iOS, WebOS, etc).  Experience with profiling, tuning, and
optimizing Java applications.  Experience with mobile video delivery
would be a plus.

Java, C++ or Objective C - Mobile Apps Developers for iphone, ipad,
Blackberry and Android.


3. Integrating orkut in android application

4. getting exception when inserting events in android calendar.

5. RTSP Example

6. Installing ADT plugin for eclipse (Debian squeeze)

7. Connect to other device through WIFI (ZeroConf/Bonjour)