Rockbox mail archiveSubject: Re: Some comments on the iFP port
Re: Some comments on the iFP port
From: Paul Louden <paulthenerd_at_gmail.com>
Date: Mon, 10 Apr 2006 15:57:05 -0500
I just wanted to say that I recently acquired an iFP-799, and while I'm not
much in the low-level programming department, I'm really looking forward to
the port. Just as a bit of information the iPod port runs on a 75mhz ARM
core, and can usually play Q8 oggs well, without even boosting constantly. I
don't know if this information is terribly helpful, but I felt it might be.
Anyway, as I said I'm not much in the way of low level programming, but if
there's any means by which I can assist let me know and I'll do what I can.
On 4/10/06, Tomasz Malesinski <tmal_at_mimuw.edu.pl> wrote:
> I haven't had much time for Rockbox recently and I will not have much
> of it in the following weeks. I just wanted to show that I'm alive and
> discuss some things that are important for the iFP port.
> 1. Adjusting what is in IRAM and what is not.
> I started implementing the idea discussed some time ago on IRC. I
> introduced macors like IBSS_ATTR_MPC_SAMPLE_BUF. The macros may be
> defined in config-<model>.h to be empty or not. The default values are
> defined in config.h or, as I think is better, in files like
> config-tremor.h, which are included by all files which may use a
> specific macro.
> 2. Decreasing the audio buffer size.
> There is no memory for 5s audio buffer. Currently I use a 0.5s
> (~80kB) long buffer. I guess we should create a SMALL_AUDIO_BUFFER or
> similar config macro. Crossfeeding should be probably disabled when
> using a small audio buffer.
> 3. Reusing codecs iramcopy areas.
> I tried putting codec bss over iramcopy area. It lets me save some
> precious kB. It worked (I just had to move ci = api or rb = api
> assingments after IRAM initialization). I have some problems with
> codecs (sometimes they fail to initialize after playing one song, the
> player shows "codec not found"), but I haven't checked if it is
> related to this change.
> 4. Reducing memory usage of Unicode support.
> I haven't tried it, but I suppose that we could use much less than 64
> kB for the codepage table. Either only part of the codepage could be
> loaded (on a flash player) or the codepage could be stored in
> memory in a compressed form (run length encoding could be efficient
> both in terms of compression ratio and decompression speed).
> 5. Noninterleaved output from dsp.
> The iFP hardware uses noninterleaved samples or at least I don't know
> how to make it accept interleaved ones. An option to make audio buffer
> noninterleaved could save some unnecessary processing on iFP. I
> haven't tried to implement this.
> 6. Codecs optimization.
> Although I believe I switched the CPU to 60 MHz, I have performance
> problems. After some optimizations I managed to play 80 kbps Ogg
> Vorbis file in realtime. A 192 kbps Ogg and all mp3s still skip.
> I will try to prepare clean patches in a week or two. Meanwhile, if
> you are _really_ interested you can see some not up-to-date and quite
> messy patches at:
> The Tremor codec contains optimizations of vector operations (merged
> with the Coldfire code), MDCT (block load and store instructions) and
> Huffman decoding. The MP3 codec contains only one optimization in
> synth.c, with a small impact on decoding speed. More is needed.
> Tomek Malesinski
Received on 2006-04-10