dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Implementing software codecs (for iRiver etc)

Re: Implementing software codecs (for iRiver etc)

From: Björn Stenberg <>
Date: Tue, 14 Dec 2004 13:52:53 +0100

Dave Chapman wrote:
> 1) Have low-level "private" audio device drivers in the firmware. These
> should try and abstract (but not if it interferes with performance) the
> details of the hardware. These drivers would also be implemented in the
> uisimulator, making use of the PC's sound hardware (and libmad in the
> case of the Archos simulators).

Yes, the thinking so far has been to use a simple PCM data pump, which feeds the DAC from a relatively small PCM data buffer.

> 2) Have a high-level "public" audio API accessible by the apps/
> directory. This should be the same for devices with either MPEG audio
> hardware or PCM audio hardware, and is capable of playing any supported
> file format via the use of codec plugins (some of which may be built-in).


> 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... :-)

> 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.

Received on 2004-12-14

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