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
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_



Audio cache strategies

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


 his 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:
--~--~---------~--~----~------------~-------~--~----~


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
[EMAIL PROTECTED]

--~--~---------~--~----~------------~-------~--~----~



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?

-- 
€€  €€€€€  http://www.cowlark.com  €€€€€
"All power corrupts, but we need electricity." --- Diana Wynne Jones,
_Archer's Goon_



Other Threads

1. reduce list view font size

How can we reduce list view font size?

Can any one know about these.

please reply me.

Thanks in advance

Join

2. ADC deadline drawing near

Hello,
There's about 24 hours left before the deadline. Please, please don't wait
until the last second to submit your entries. Your APK may not validate on
the submission site, so leave some time to correct any issues. You can
always update your entry later, and it's better to have something to show
for your work rather than nothing.

If you plan on updating an existing entry, again don't wait until the last
minute. And a quick heads up, you will have to increase your version code in
order to update over your previous APK, similar to how it is on the Market.

Good luck!
James

--~--~---------~--~----~------------~-------~--~----~

3. Upload a valid APK ADC2

4. Questions about ImageView.setImageMatrix

5. Paid App Protection, a problem of the whole Android ecosphere

6. Do you got any confirmation after ADC 2 submit?

7. Any email confirmation after submit the application for ADC 2?