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

[Jonathan C. R. <jon...@ba...>]

Hi again, Bernard,

On Tue, 2004-04-20 at 10:43, Bernard Leach wrote:
> 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 ;)).

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.

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....

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?

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?

> 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.

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.

> 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? ;)

> 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.

Catch you soon,
	Jonathan.