This is exactly the sort of problems my application (http://
five.googlecode.com) 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
chokes.
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:
> 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
> length.
>
> 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?
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com─────
> │
> │ "All power corrupts, but we need electricity." --- Diana Wynne Jones,
> │ _Archer's Goon_
>
> signature.asc
> < 1KViewDownload
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
Announcing the new Android 0.9 SDK beta!
http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
