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



Rockbox mail archive

Subject: Re: IRAM patch and swapping codecs

Re: IRAM patch and swapping codecs

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

"Steve B" <pondlife_at_ntlworld.com> wrote in message
news:eiulrc$29j$1_at_sea.gmane.org...
> 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
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.
>
> 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
is
> that the voice thread is needed, but should be able to feed PCM data to
the
> 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 was last modified "Jan 10 2012" The Rockbox Crew
aaa