dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: IRAM patch and swapping codecs

Re: IRAM patch and swapping codecs

From: Michael Sevakis <>
Date: Thu, 9 Nov 2006 10:21:03 -0500

"Steve B" <> wrote in message
> Hi Tomasz
> I'm no expert on the IRAM stuff, but no objection here.
> > > 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
> > the moment until I was sure there'd be no way a swap could be attempted
> > any codecs with no buffer available to use. I find it not entirely
> > to determine. I've been told there is a patch to just exchange the
> > using a single buffer.
> A single buffer would be an improvement. All we need is a suitably
> optimised memswap() call. Even better, would be a removal of the swapping
> and corresponding mutex.

As long as we don't use a built in voice codec or one relocatable, the two
must use the same memory space since they must both use the same addresses
as each other when active. An optimized memswap for swapping would a simple
implementation if it can assume appropriate alignment.

> > I'm not sure that a voice thread is even necessary 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.
> Not sure I totally understand this either, but bear in mind that the voice
> output should work at all times - whether music is playing, stopped or
> paused (something that is currently broken). My (uninformed) gut feeling
> that the voice thread is needed, but should be able to feed PCM data to
> output entirely freely and without interacting with the codec thread - i.e
> they should be peers, with no swapping/mutex/swap buffers required.

I wouldn't change the perceived behavior of the system. I gave a look and
the voice codec does get swapped in and run during playback to mix playback
with voice in codec_pcmbuf_insert_split_callback then voice swaps the audio
codec back when it's done and the callback then returns. The voice thread
must wait inside the codec waiting for its data which makes the voice thread
nescessary _currently_. It is obvious to me now that a codec that operates
differently than normal audio codecs (a push, not pull model instead) should
be used and the second thread would be entirely unneeded.

> Steve B
Received on 2006-11-09

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