Re: [Ipodlinux-devel] status update 17.02.03

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

Hi Chandan,

Not sure if you got to do any experimentation, but I've just tried what
you were suggesting.

First up I reverted to just using a single cpu to drive the audio.  The
results were (using the mp3example) a noticible slowdown.

The second experiment was to put some of the ipp code into the fast ram
and try that.  This turned out to be a little harder than first hoped
(since I don't have the source code to that).  Anyhow with those changes
the performance was back up to near real-time.  It is definitely less
than the original cpu-cop version but this version is only using one
processor!

My current feeling is that using this cpu-only audio driver is the right
way to go (and then to use the cop as a decoding unit..?).  Or at least
using the internal ram for buffering is a big waste.  I suppose a
cpu-cop driver using sdram and cache flushing would be one more
experiment there...

I'll see about getting the audio driver into CVS so it can be compiled
as either.

The mp3example program on the other hand is a bit of a nightmare!  To
get this to work I compiled up a dummy program that called the functions
to relocate and compiled it to 0x40000000.  This program is then copied
to the right location and then stubs are used to call to the right
spot.  Does anyone have any suggestions as to how this could be
simplified?

cheers,
bern.

On Tue, 2003-03-04 at 16:04, Chandan Kudige [home] wrote:
> In the current implementation of cop code, everytime an application
> tries to write more than one frame of data to the /dev/dsp, it will be
> put to sleep as long as the kernel keeps feeding this data to the cop
> (I think the shared SRAM is 92K only)
> 
> One way to handle this would be to implement a kernel thread which would
> take the user data and keeps feeding to the cop. This thread would be
> sleep most of the time, and the user program can continue its execution
> in parallel. I still havent tried this out.
> 
> Intel's mp3player writes one frame at a time and hence does not incur
> this waiting. But I can verify by playing it to /dev/null just to be
> sure.
> 
> So if we can do away with the cop and write to the audio in the main
> processor we can still follow this approach so that we do not tie up the
> user process. We can still move the decoding routine into the SRAM (I
> would assume that 92K should be more than enough!).
> 
> I can give this a try over the weekend.
> 
> -Chandan
> 
> On Tue, 2003-03-04 at 03:44, Andre wrote:
> > Bernard Leach <le...@bo...> wrote:
> > > 
> > > An extension of that would be to then put the decoding routines
> > > in fast ram (since we wouldnt be using it as the buffer).
> > > I'm not sure how big a win this would be but it is how the real
> > > firmware works...
> > > 
> > 
> > My guess is that this will be a _big_ win. The internal SRAM is
> > likely to be 32bit wide, with low (probably zero) wait-states when
> > accessed from the ARM.
> > 
> > The system SDRAM on the other hand (Samsung part No. K4S561632 ??) is
> > 16bit wide, has the overhead of refreshes etc and is probably clocked
> > slower as well (anyone with an open ipod and a 'scope handy, please
> > put a probe on pin 38 of the SDRAM chip and let us know for sure...
> > :-).
> > 
> > The most important code in madplay to speed up is the imdct36
> > assembler function and the contents of synth.c. The later may take a
> > bit more work, but the former is fully PIC so a quick and dirty test
> > would be to hack madplay to memcpy the whole of III_imdct_l into fast
> > SRAM at program startup and then call it from there via a function
> > pointer (its only called from 2 places in layer3.c).
> > 
> > How big is the internal SRAM by the way ???
> > 
> > Andre
> > --
> > 
> > 
> > 
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
> > for complex code. Debugging C/C++ programs can leave you feeling lost and 
> > disoriented. TotalView can help you find your way. Available on major UNIX 
> > and Linux platforms. Try it free. www.etnus.com
> > _______________________________________________
> > iPodlinux-devel mailing list
> > iPo...@li...
> > https://lists.sourceforge.net/lists/listinfo/ipodlinux-devel
> > 
> 
>