Rockbox.org home
dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Implementing software codecs (for iRiver etc)

Implementing software codecs (for iRiver etc)

From: Dave Chapman <dave_at_dchapman.com>
Date: Mon, 13 Dec 2004 15:08:39 +0000


I was wondering how much work has been done on implementing software
codecs within rockbox in preparation for the upcoming (we hope) iRiver port.

I've always wanted to see (or more accurately, hear) audio playback in
the UI simulator and that capability would seem even more useful when
implementing software decoders.

Looking towards the future, I would imagine that we would need the
following abstractions in the rockbox build system:

1) Audio hardware capabilities - which audio formats can the hardware in
the target device handle?. For the Archos devices it is MPEG audio, for
the iRiver it will be PCM (with limits on word size and sample rate),
other future devices could have other capabilities.

2) CPU capabilities. Software codecs will obviously be limited by the
power of the CPU in the target device (and maybe other features such as
amount of RAM and speed of the storage device). Some codecs won't work
at all on some devices, and some codecs may be limited to low bitrates.

It also seems inevitable that iRiver users will start to want support
for all kinds of obscure codecs, but most users will only use a small
number depending on their personal needs. Do people agree that it would
therefore be sensible to implement codecs as plugins? Should some
codecs (e.g. MPEG audio and WAV) be compiled into rockbox, or should
everything be a plugin?

The differing hardware capabilities also means that Rockbox will need
two copies of libmad - one in the uisimulator directory for the
simulation of the MAS decoder in the Archos devices, and one in the
"codecs" section for the software decoding of MPEG files for feeding to
audio hardware supporting PCM audio.

I would like to start work on implementing some of this stuff, but don't
want to either duplicate work that's being done by others, or go off in
the wrong direction.

Although I've only really thought about decoders, the same issues (and
solutions?) will apply to encoders as well. But one difference is that
encoders do not necessarily have to be able to work in real-time.

Apologies if this discussion has already happened and I've missed it.


Received on 2004-12-13
