From: Dave Chapman <dave_at_dchapman.com>
Date: Tue, 14 Dec 2004 13:59:29 +0000

Björn Stenberg wrote:
>>One issue is whether Rockbox should load and initialise all codecs at
>>startup (with serious consequences for memory use), or load and remove
>>them as needed.
>>
>>I am assuming we should do the latter, even if it results in short
>>pauses when changing playback from one codec to another - gapless
>>playback of files of different types doesn't seem high on the list of
>>priorities.
>
>
> I disagree, introducing unnecessary gaps between songs is quite
> annoying and ... not our style. :-)
>
> Actually we only need to have two decoder slots, one for the
> currently playing track and one for next track (if different from
> current). Switching back and forth between codecs will then only
> "cost" an extra spinup, but no gap. (Unless perhaps if you play a
> directory full of 0.5-second tracks... :-)

I agree that gapless playback is a good thing, but it is only NEEDED
when playing back live concert recordings or other cases where one long
recording is split over different files.

All I am saying is that if two files are encoded in different formats,
then they are very unlikely to be two parts of the same recording.

But this should be an implementation issue, rather than a API issue -
the loading and unloading of codecs should be controlled by the firmware
(based on available hardware resources), not the application.

But I agree that two decoder slots should be feasible.

>>This then leaves the problem of how does rockbox know the capabilities
>>of a codec if the codec isn't loaded, and therefore unable to be
>>queried. This may not be as simple as just using file extensions - a
>>".ogg" file could contain either flac or vorbis (or speex) data.
>
>
> We already load the id3 tag from files when we buffer them. Adding a
> codec discovery function is a logical extension of this step.
>

Agreed. But where do you propose that the logic inside the codec
discovery function lives? We don't want to have to patch the core
rockbox in order to support new codecs.

Codecs need some way of telling the discovery function which formats it
can handle AND how to detect that a file is in one of those formats.
Maybe this logic could be expressed be a "codecs.conf" file (containing
rules similar to the "magic" file used by the Unix "file" command).

Or maybe for the sake of efficiency we do want the codec discovery logic
(or at least some of it) to be hard-coded into Rockbox.

Another issue is whether code that deals with generic container formats
such as OGG should be seperated from the code that deals with the actual
decoding of the data. This is how most generic PC media players work.

My view is that we shouldn't bother - there are not enough generic audio
container formats in use to make the complications worthwhile. Codecs
can share source code (e.g. libOGG) if they share container formats, but
should compile to standalone plugins handling both the container and the
audio data.

Dave.
_______________________________________________
http://cool.haxx.se/mailman/listinfo/rockbox
Received on 2004-12-14