Re: [Ipodlinux-devel] status update 17.02.03

[Chandan K. [home] <ch...@to...>]

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
>