Best ways to handle large memory allocations?

[Jona]

Currently I have implemented a circular buffer in the java layer using a RandomAccessFile with rw flags.  I use this buffer to store up to a max 140MB.  This method seems to be rather slow on some devices and also doesn't work on devices with no external storage available.  This data is accessed continuously since its cached audio data and it's used for playback with seeking support.

I'm looking to implement my circular buffer using the NDK and storing the data directly to memory and not a file.  I know that memory allocation doesn't have a limit but 140MB sounds like a bit too much. 

What is the minimum max memory size that one could see on devices running Android 1.6 and greater?

What would be the largest recommended memory allocations?

Any better suggestions?

[RichardC]

How about using mapped files and caching into it?

[Dianne Hackborn]

On Sat, Jul 21, 2012 at 8:56 AM, Jona <medica...@gmail.com> wrote:

What is the minimum max memory size that one could see on devices running Android 1.6 and greater?
What would be the largest recommended memory allocations?

This varies across devices, not version numbers.  These APIs give you guidance for allocation limits for a particular device:

http://developer.android.com/reference/android/app/ActivityManager.html#getMemoryClass()

http://developer.android.com/reference/android/app/ActivityManager.html#getLargeMemoryClass()

Note that 140MB is going to be really pushing it for lower-end devices.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

[Jim Graham]

On Sun, Jul 22, 2012 at 10:53:17AM -0700, Dianne Hackborn wrote:

> Note that 140MB is going to be really pushing it for lower-end devices.

I'll second that. My Motorola Bravo (MB520), which I plan to replace the
very first DAY I'm able to, is doing rather well right now---it has a
whole 103 MB of RAM free, and that's high compared to its idea of "normal".
It definitely qualifies (IMO) as a low-end device...and to make it worse,
it's stuck at Froyo. Fortunately, I've moved just about everything I
once used it for over to my tablet, and it's only a phone and a test
device now...and when I replace it, it'll be a paperweight (and a test
device).

Later,
--jim

--
THE SCORE: ME: 2 CANCER: 0
73 DE N5IAL (/4) | 1) "Smoking habanero powder helps defeat that
< Running Mac OS X Lion > | off taste' quite nicely."
spook...@gmail.com | 2) "I figure a couple bong hits of [habanero]
ICBM/Hurr.: / 30.44406N | powder would defeat just about anything!"
| 86.59909W --seen in Chile-Heads list

Android Apps Listing at http://www.jstrack.org/barcodes.html

[Glenn Kasten]

For a circular buffer cache of audio data, consider encoding to a more memory-efficient format in the background. Depending on quality needed and CPU power available, you could use a lossless format such as FLAC, a fast-to-encode but very lossy format such as IMA ADPCM, or a traditional music encode format (MP3, AAC, etc.). You could also encode very recent data using lossless, and then older data using a lossier format. This would allow you to need less RAM while still preserving good quality esp. for recent data.

[Jona]

Thanks Dianne for your post... The memory limits are only for java layer, is there a way to check actual phones memory size? Using that information I could possibly limit per-device max cache limit.

[Jona]

@RichardC Mapped files could work actually, but I'm not sure if this would be effective since my read pointer could be at the start of the buffer and my write pointer at the end of the buffer. Wouldn't that cause the file to be mapping the start of the buffer then the end of the buffer?

@Jim Graham Thanks for your info about the low end devices... Yeah I guess 140MB would be killing these small devices...  I might need to design a paging type of circular buffer.

@Glenn Kasten Well the thing is I stream live radio content of any format.  Transcoding this to a loosy smaller compression would mean extra CPU usage and more battery consumption.

[David Given]

Jona wrote:
> @RichardC Mapped files could work actually, but I'm not sure if this
> would be effective since my read pointer could be at the start of the
> buffer and my write pointer at the end of the buffer. Wouldn't that
> cause the file to be mapping the start of the buffer then the end of the
> buffer?
>
> @Jim Graham Thanks for your info about the low end devices... Yeah I
> guess 140MB would be killing these small devices... I might need to
> design a paging type of circular buffer.

Mapped files all work through the Linux VM, so they're intrinsically
both paged and cached in RAM. If your device has enough RAM to hold the
whole thing in memory, it will; if not, it'll be paged to disk
automatically.

Of course, a low end device won't have much disk, and using a circular
buffer that won't fit in memory will require continually writing to
disk, which is considered antisocial on flash. It would be best to try
and reduce the buffer on such devices, but I don't know how you'd be
able to tell what size would fit or not.

--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams