Rockbox mail archiveSubject: RE: Re: another 8MB upgrade success story
RE: Re: another 8MB upgrade success story
From: Justin Heiner <jheiner_at_yahoo.com>
Date: Wed, 19 Mar 2003 17:57:02 -0700
If it's good *solid* code, and the benefits of it outweigh the downside, then I would assume that it would be demoticratically discussed by the rockbox community and ultimately decided by Bjorn, no matter which way the votes go. :-)
About developing it by a non-primary developer, I would say that it has more to do with the quality of the code than the status of the developer.
---------- Original Message ----------
From: Leif Sawyer (lsawyer_at_gci.com)
Subject: RE: Re: another 8MB upgrade success story
Date: 3/19/2003 5:16:02p
> Uwe continues the thread with:
> > With a 2 MB AJB, you have 1,7 MB free memory for MP3 buffering. The
> > 8MB-modified Jukebox has 7,7 MB for buffering and the gain in battery
> > runtime is 15-30%.
> > So if you add dynamic memory allocation so that you can use 1,8 MB
> > with a 2MB AJB instead, I think it will give you another percent
> > running time or so - alsolutely not worth implementing dynamic memory
> > management IMHO.
> Well, it's all about cost tradeoff, right?
> In this case, the cost is the amount of time to develop the dynamic
> memory management scheme. The benefit is scalability for better
> buffering (whether on 2Mb or 8Mb) and possibly automatic support for
> units with more than 2Mb of onboard RAM.
> In order to keep the cost down, we could only implement initial dynamic
> memory allocation. This meaning that when rockbox boots up, it figures
> out how much ram is available and bases the buffer sizes on the current
> This benifits both sides, with minimal effort and impact. We're still
> not dynamically "tuning" the memory based on the current applications,
> so complexity is significantly reduced. This also has the added benefit
> of being "ready" for the next HW rev of the AJR/FM/xxx with more than 2M
> of ram. (Ok, we don't know if they'll do this, but we'd be ready!)
> If this were to get developed by a non-primary developer, would it be
> a possibility for mainline inclusion?
Received on 2003-03-20