From: Bernard L. <le...@bo...> - 2004-04-20 08:43:13
|
Hi Jonathan, sounds like you're making some really good progress there! It would be really neat if we could get libmad decoding at full speed. The big win there will probably be if we can move some of the data that is accessed frequently into the on-chip ram. The only question is which data to move. Currently the onchip ram is used as a circular buffer for buffering data that is to be written to the DAC (the CPU is a produced and the COP a consumer on this buffer). At the moment it is using the entire 96K for that purpose so if that were reduced then some could be used by the user process. (E.g. just create a pointer to 0x40000000 somewhere ;)). Regarding the big malloc problem that is a little strange. The patches in the mp3example player malloc up a chunk large enough for the entire file so you can definitely malloc more than 512 bytes. The uclinux 2.4 has a special slab allocator (non power of 2 version) which we use to allow big mallocs. (Sofar 2.6 doesn't have one so I'm not sure what the plan there is). In /proc are some files which can give you some status on the memory subsystem. I can't remember their exact names but they should be fairly obvious. As for the -ipod0 and ftp problems the default ip address changed to 192.168.222.2, maybe that is causing you some problems? Anyhow looking forward to seeing some of your patches ;) cheers bern. "Jonathan C. Ross" <jon...@ba...> said: > Hi Bernard et. al., > > As mentioned before on the mailing list, I am working on a play > queue/multi song buffer, and incorporating mp3 playback into podzilla. > In the process, I have run into a problem with memory management. After > coding and testing on the host (works great with libmad!) I > cross-compiled and installed the app on my iPod. Upon initialisation I > allocate 16M for the buffer, but this fails on the iPod. (Okay, I > probably need to allocate several blocks instead of one chunk, because > there is definately more than 20 M free, albeit not contiguous.) I then > wrote a simple-minded programme to probe the maximum amount of > contiguous memory: > > int main() > { > int bytes = 1; > char* buffer; > > while (buffer = (char*) malloc(bytes * sizeof(char))) { > free(buffer); > printf ("success with %d bytesn", bytes); > bytes <<=1; > } > > return 1; > } > > The app hangs after 64-512 bytes, with endless errors scrolling by on > the lcd display, too fast to read. I am invoking the app via telnet > with the 2.4.24-ipod0 kernel. I have not tried it standalone. As there > are examples of malloc in existing code, I can only presume that there > is a problem with free(), or that I am missing the point entirely... (I > haven't coded plain c in a couple of years). > > Anbody else seen this behaviour? If not, any pointers as to how I can > debug it? (Slowing down the console messages would be a start!) > > A quick update on my progress: I have built a standalone libmad app with > console input (play/pause/quit) and with a modest (1 song) buffer (using > mmap). This works fine on the iPod, except of course that it is not > 100% real time... (a couple of tweaks in the configuration of libmad did > improve matters drastically though! I still have hope...). Otherwise, > I have built a circular buffer for multiple-track caching into > Podzilla. Playback is incorporated into the main loop by decoding a > single frame in between each successive poll of the event loop. > > As soon as I have sorted out the allocation problems and tidied up the > code a little, I will post my patches. > > Thanks, > Jonathan. > > P.S. since I upgraded to the ipod0 kernel, I have not been able to ftp > -p 192.10.1.1 anymore. Anyone know what's going on there? > > > > > ------------------------------------------------------- > 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 > -- |