|
Rockbox mail archiveSubject: Re: IRAM patch and swapping codecsRe: 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 template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |