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

[Bernard L. <le...@bo...>]

"Jonathan C. Ross" <jon...@ba...> said:

> Hi again, Bernard,
> 
> 
> Whoa!  The entire decoder should work directly in that memory!  Isn't
> ~16-32K enough for the DAC buffer?  Should I just reduce DMA_BASE (in
> audio.c) and then 'allocate' a decoder circular buffer somewhere after
> that?  I reckon having the decoder struct and the bit stream buffer in
> the on-chip ram will be good enough, but perhaps we'll have to get the
> Huffman tables and some of the code on there too...  We'll see.

I'm not sure of what good values would be.  Some profiling/experimentation is
needed.  One reason the DAC buffer is even there in the first place is that
the COP/CPU have separate data caches (non-snooped) so they can see
inconsistent views of SDRAM, the chip ram isn't cached so there is no problem
there.  This could be fixed by cache flushing (I have the basics of that
sorted but not-implemented) and then that buffer could be moved to sdram.

Apple's firmware definitely sticks code in there (that looks like audio stuff)
but I'm not sure.  If you define a special linker segment for 0x40000000 and
then relocate the decoder there that might be a good speedup.

What we really need though is some kind of profiling on memory usage for the
decoder.  Perhaps something like the Armulator does this (or could be
modified).  If we knew a little more about the memory usage pattern then it
would be easier to optimise usage of the fast ram.
 
> Doing it in user space definitely makes sense for now - but when we've
> gotten that working, I reckon it would be smart to actually move the
> decoder to the kernel.  We could use the AFMT_MPEG for the
> SNDCTL_DSP_SETFMT call, looks quite clean to me...  ( Why isn't there an
> AFMT_OGG value defined in <linux/soundcard.h> ? ;) )  And then we could
> migrate it to the COP so it could do something more than feeding the
> DAC....

Sure, thats the long term plan.

> Before I start work, which kernel/cvs-branch would you rather I worked
> in?  I haven't actually migrated to 2.6 yet; should I?

2.4.  2.6 is great except that it corrupts any disk you mount read-write ;) 
Most of the drivers are 1-1 copies sofar and will stay that way until the IDE
is sorted (at which point 2.6 will becomee my dev platform).
 
> Next question: how is the work on a mixer device coming?  It would be
> neat to have a prototype 'now playing' window with volume control within
> the near future.  Or is there an ioctl for accessing d2a_set_vol
> directly?

Last night I was working on audio recording, once that is working I'll add
mixer support.  It should be pretty easy as the only part missing is the Linux
device plumbing that connects userspace to the d2a_set_vol.
 
> > 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).
> 
> Yeah, I saw the malloc() in the patch...  I also didn't have any
> problems with an mmap of ~7M in my prototype libmad code.  My problem
> seems to simply be related to successive malloc/free calls.  It would be
> good to know if anybody can reproduce this with the code I posted
> earlier.

Ok, that is strange.  I'll give it a go next chance I get.

Are you using a particular version of uclibc?  Or just the one in the
toolchain?  Which toolchain version?

It could be worth checking the uclibc and uclinux mailing lists.

> Actually I'm not so sure I was using the 2.4.24-ipod kernel any more - I
> remember installing it, hearing that the mp3example playback was worse
> than in the rc2 kernel and then rolling back (I probably should have let
> you know this when you did the release...)  I'll try reproducing the
> memory problem with various permutations of stand-alone, telnet and the
> various kernels if I have the time, and tell you how I get on.

What was the mp3example playback problem?  I didn't realise there was any
difference between rc2 and the final version there... Its possible that I
upgraded my toolchain for the final version but I'm fairly sure I didn't.

Anyhow I realise what a PITA that type of testing is but any info you come up
with would be great.
 
> > 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.
> 
> anything other than /proc/meminfo I should look for? ;)

/proc/slabinfo and there is a new uclinux one that shows the memory map.

> > As for the -ipod0 and ftp problems the default ip address changed to
> > 192.168.222.2, maybe that is causing you some problems?
> 
> Well, as I can connect, run ls/cd etc..  No, I don't think the IP
> address is the problem.  All works fine except for the actual transfer. 
> Again, this is actually with the rc2 kernel, not 2.4.24-ipod.

Oh, strange again.  I normally use wget from the iPod to fetch stuff from the
PC with http.  I'll try with ftp...

cheers,
bern.