> > Patching the PCM codec into Rockbox for Archos is not not a trivial
> task. If
> > done properly, it's an opportunity to renovate the playback+recording
> > like keeping the bitswap away from the big buffer, a different concept
> > metadata of buffered files, a frame walker for mp3, trick modes, etc.
> > liked to have done that, but other priorities got in the way.
> That's a pity! But does it really need to renovate the whole playback
> and recording code and do the other things you mentioned?
It would save overall effort. The framewalker is not necessary in the first
step, admitted, but on our todo list.
> As a start I would be completely happy if someone wrote a plugin for
> WAV/PCM recording and a plugin (probably a viewer!?) for WAV/PCM playback!
That's a lot of throwaway code and duplicate work. Perhaps it makes sense to
do first experiments in a plugin, for not tearing up the whole thing while
the way is still unclear, but that'll be a developer toy.
> > For full quality wav pumping, our poor CPU would be pretty busy with
> > bitswapping.
> Could you explain why the recorded data has to be bitswapped? Do the
> most significant byte and the least significant byte have to be swapped
> in order to get a proper WAV stream?
It's a shortcoming of the serial interface. It streams the bits in UART
order (LSB first), but internal serial interfaces are SPI, which is MSB
first. Since the order can't be programmed, we have to twist every byte,
can't DMA it directly.
Currently, we have a process which flips the byte in the big buffer, but it
turned out to be better to flip in small pieces directly before outputting.
The benefit is that the big buffer stays intact for parsing, has only one
A similar problem exists for the disk I/O, here we have to endian swap byte
pairs. Archos unfortunately wired the 16 bit data bus directly 1:1, not
taking into account that IDE is little endian and the SH CPU is big endian.
Both of the above keep our CPU from becoming bored.
> It would be perfectly alright as a start to just be able to write the
> plain PCM data to disk (with the said plugin) and to do the post
> processing (e.g. bit swapping and adding of a WAV header) later on the
> PC. This would also prevent the Jukebox CPU from becoming too busy.
Another thing: the PCM codec wants a strange framing format, a 4 byte header
with the ASCII chars "WAVE" every 1024 samples. We either place that into
the buffer, too, or attach it at the output stage.
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Received on Wed Jan 25 10:13:42 2006