Re: [Ipodlinux-devel] Memory (de-)allocation problem

[Matthew J. S. <ge...@do...>]

Fair enough, but the search for the contiguous memory still seems like reimplementation.  Even if you want a couple frames of 24 songs, you could easily split those frame and then use the sizes of those for your malloc call.  Either way your ultimate goal it to just keep track of them with an index. so to speak.  Then once someone flips to that song it rips those initial frames from the memory location and starts to read the rest off of the disk.  Either way, my statement about reimplementing had to do with finding contiguous blocks of memory, which seems for the most part, unnecessary, assuming you have a good enough method for tracking where the initial frames are loaded.  One idea I had originally was a RAMDISK (which would also seem to solve your problem rather easily (at least with whole songs).  I was looking forward to a RAMDISk for various parts of podzilla -- including graphics that get displayed as part of the software.  Maybe the RAMDISK could simply be pushed forward for what you're going to use it for... not sure.

On Tue, 20 Apr 2004 12:26:31 +0200
"Jonathan C. Ross" <jon...@ba...> wrote:

> Hi,
> 
> I think you're overlooking something here... What if the track exceeds
> physical memory in size?  (I don't know whether you've tried playing a
> long movement of a symphony or an audio book with the patched
> mp3example, but believe me, it won't work ;-) ).
> 
> It's not like I'm trying to re-implement the functionality of the memory
> manager anyway - I'm just trying to use it.  My problem was encountered
> when invoking free().  ( In the worst case, there is actually something
> physically wrong with my iPod ;). )
> 
> The way I see it, we can copy Apple's caching mechanism - have 'up to 4
> songs cached' (i.e. around 16M), and even improve on it.  The
> improvement would be in caching the first couple of frames of a larger
> number of songs - say, the next 12 songs, and the last 12.  The
> improvement here is that, in my experience, one tends to skip tracks
> very frequently when playing large playlists.  When you skip forward two
> or three tracks you get a cache miss, and the unit hangs while the disk
> spins up.  By caching 'heads' of the songs, we'll have a much more
> responsive play queue.
> 
> Cheers,
> 	Jonathan.
> 
> On Tue, 2004-04-20 at 23:36, Matthew J. Sahagian wrote:
> > Forgive me if I'm mistaken about what you're trying to do,
> >  but would it not be possible simply to get the songs 
> > chosen for play, and attempt to allocate memory per song, 
> > and just retain a list of where these songs are in memory 
> > and then point to those for playing?  It seems sort of 
> > strange that you're trying to re-implement something 
> > that's technically built into the memory manager.  
> > If there is no contiguous block large enough to hold 
> > the mp3 then you could attempt to split, and store 
> > half in one part half in another, and continue to split 
> > until it does fit... just an idea.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> iPodlinux-devel mailing list
> iPo...@li...
> https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
>