Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide
translations



Rockbox mail archive

Subject: Re: IRAM patch and swapping codecs

Re: IRAM patch and swapping codecs

From: Michael Sevakis <jethead71_at_sbcglobal.net>
Date: Wed, 8 Nov 2006 19:01:16 -0500

----- Original Message -----
From: "Tomasz Malesinski" <tmal_at_mimuw.edu.pl>
To: <rockbox-dev_at_cool.haxx.se>
Sent: Wednesday, November 08, 2006 6:05 PM
Subject: IRAM patch and swapping codecs


> Hi everyone.
>
> I have two questions.
>
> Iriver iFP has small amount of IRAM, so I need to put some things out
> of it. I posted a patch (FS#5857) some time ago which controls what
> goes to IRAM on different targets.
>
> I simply define {ICODE,IBSS,IDATA}_ATTR_PURPOSE macros, which are
> either defined to be empty or to Ixxx_ATTR. The defaults go to some
> file specific to the purpose, the target specific settings go to
> config-xxx.h
>
> I need this patch, so I just wanted to ask if you would like it to be
> different. If noone complains I will commit it.
>

I would like to control the particular bank so I can deliberately use DMA
compatible IRAM on the mcf5249. Is anything like that considered here? Right
now it's treated as one single block with no distinguing properies.

> The second thing is codec swapping. Do we really need two codec
> buffers with voice turned on and one without the voice? With voice
> turned off we do not need a buffer, with voice turned on one buffer
> for the codec that is not in use is enough?

This is something that needs addressing for sure. I left things alone for
the moment until I was sure there'd be no way a swap could be attempted on
any codecs with no buffer available to use. I find it not entirely trivial
to determine. I've been told there is a patch to just exchange the codecs
using a single buffer.

I'm not sure that a voice thread is even nescessary frankly. The voice
thread can't possibly be doing anything but waiting for the mutex during
playback (codec thread already owns it when an encoder is loaded) so it must
be handled elsewhere. Seems the codec thread could handle it during stop too
and a swap could be single thread and the playback engine could be
simplified. Tell if I'm wrong, please.

Michael Sevakis

>
> I may provide a patch for this, but I can't test it with the voice
> enabled. I have too little RAM in iFP to run it with voice.
>
> --
> Tomek Malesinski
Received on 2006-11-09

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy