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



Rockbox mail archive

Subject: AW: separating file read and mp3 playback

AW: separating file read and mp3 playback

From: <phil_at_carangg.de>
Date: Mon, 29 Dec 2003 15:10:54 +0100

> Von: [IDC]Dragon
> Data source would be some code that supplies mp3 data into
> buffer(s). Data sink is another code that takes such
> buffer(s), maintains DMA and notifies about consumption. Not
> shure where to place the bitswap, it could even be an object
> in the middle. Recording is similar, the source would be the
> MAS then, sink is a file writer.

I came across the similar ideas when trying to implement looping. I too
think it would be a good idea to change things here. The file api is
nice and simple to use but makes a lot of things difficult as soon as
you want finer control on what is being played / recorded. E.g. looping
is a functionality that I'd prefer to be implemented on the apps side
rather than the firmware side. That's nearly impossible. Recording with
a prebuffer is another example. That too is questionable to be placed in
firmware, but as it is the firmware that writes the file you can't
control the data stream before.

The mas is a streaming device. If rockbox started now again I'd fight
for a stream approach. Playlists would be streams. Files would be
streams. Bitswapping would be a pipe.

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.

> the UI could also emit clips for blind usage,

Are you talking about eg. beeps on button press while playing back? The
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 volunteer to do my best with the architecture (have
> experience with such), but am lost with all those special
> quirks in mpeg.c (can't maintain that), please help with the
> requirements. Am I able to spin up some inertia for this?

I myself have not written a single bit in mpeg.c and hardly understand
anything of it. Even after reading docs/TECH I had rather little
enlightment. Yesterday I talked a bit with Linus
(http://rockbox.haxx.se/irc/rockbox-20031229.txt) about the principal
mechanisms for playback / recording. Key experiences for me were:

- for playback the MAS is fed via a serail interface
- in the cpu the data source of the derial interface is dma
- DEI is the interrupt fired when dma has finished transferring
- recorder: MAS uses its DEMAND signal to inform the cpu
  via IRQ3 that it is hungry
- player has no interrupt for this and must poll for the
  DEMAND signal of the MAS
- MAS informs the cpu via IRQ6 that it is fed up

But I really am very far way from being a guru in these things.

Phil
Received on 2003-12-29

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