Rockbox mail archiveSubject: Re: WAV Codec for Archos
Re: WAV Codec for Archos
From: Christoph Niedeggen <Niedeggen_at_gmx.net>
Date: Wed, 25 Jan 2006 23:49:21 +0100
> 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.
Aren't most of the existing plugins just developer toys? ;-)
I'm really wondering if anybody already has done some experiments
(playing / recording) with the WAV/PCM codec? Any comments?
If nothing should have been tested yet at all, it might be that the
developers are held off from testing the codec at all just because the
goal is set to high (i.e. implement everything into the main Rockbox
code and make it perfect from the start.)
In my opinion it might be a much better way to first test the
implementation and function of the codec by writing some plugins.
Unfortunately I am not a developer, but I guess that programming a first
working plugin for recording PCM data and for playing PCM data should
take just a couple of hours. Please correct me if I'm wrong!
> 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
From what you're writing it seems to me that you already did some
testing with the codec. Is that right? What are the results?
> 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.
Isn't there the same problem when playing/recording MP3 data? Or does
the built-in MP3 codec take care of this?
>> 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.
I don't think that my idea is too bad at all, since e.g. the video
plugin does in a way exactly the same (processing data that cannot be
handled by the Rockbox CPU simply outside of the unit.)
That doesn't mean that I wouldn't really like if the necessary bit- and
byteswapping and adding/parsing of the WAVE header would be done within
the Jukebox unit by the software. I just think that the goal shouldn't
be set too high for the start and that the code can be improved once the
basic things are running.
Received on 2006-01-25