Rockbox mail archiveSubject: Re: AW: separating file read and mp3 playback
Re: AW: separating file read and mp3 playback
From: [IDC]Dragon <idc-dragon_at_gmx.de>
Date: Mon, 29 Dec 2003 18:25:58 +0100 (MET)
> Converting the architecture _now_ is late. There's so much code that
> would have to be rewritten - and I won't do it. That's why I kept my
> mouth shut.
It's never too late. I'd do the new part, but the existing mpeg.c is over my
> > the UI could also emit clips for blind usage,
> Are you talking about eg. beeps on button press while playing back?
I wasn't thinking of while playing, that's too problematic. But since you
mentioned, if we have a linked list of queued buffers, such a clip could be
inserted to the front. Trouble if parameters (sample rate, etc.) are different.
> problematic with this is latency due to buffering. The "mas playback
> drain" would have to supported a mechanism for a kind of sidekick stream
> so that a beep stream could be inserted at the head of the playback
> stream. This is problematic as I don't see a way around reserving
> additional buffer space in the precious ram that would be dead for the
> buffering of the playback stream...
I was more thinking about loading a UI sample set into the buffer when the
unit is idle, to be kicked out again on playback.
But the main thing to me is the ability to pump the playback at all, for
different file readers or game sound effects.
-- +++ GMX - die erste Adresse für Mail, Message, More +++ Neu: Preissenkung für MMS und FreeMMS! http://www.gmx.netReceived on 2003-12-29