|
Rockbox mail archiveSubject: AW: separating file read and mp3 playbackAW: 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 |