Rockbox mail archiveSubject: Re: Implementing software codecs (for iRiver etc)
Re: Implementing software codecs (for iRiver etc)
From: Linus Nielsen Feltzing <linus_at_haxx.se>
Date: Mon, 13 Dec 2004 21:26:45 +0100
Dave Chapman wrote:
> I was wondering how much work has been done on implementing software
> codecs within rockbox in preparation for the upcoming (we hope) iRiver port.
Not a single byte has been coded. However, we did conduct an experiment
where we replaced the hardware decoder with LibMAD on the Archos
jukebox. The playback was of course not in realtime, but it worked.
> Looking towards the future, I would imagine that we would need the
> following abstractions in the rockbox build system:
> 1) Audio hardware capabilities
> 2) CPU capabilities.
Ack on that. We will need to implement a nice API for PCM playback as
well as nice API:s for the codecs as well.
> 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?
I think the basic ones should be compiled-in, but if having everything
as plugins makes things simpler, I'm for that too.
> 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.
No, we don't need two copies, only compile it differently for the target
and the simulator.
> 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.
I suggest you come up with a suggestion on the API:s on the mailing list
and /or the Wiki, and we'll discuss it.
> 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.
Don't worry, we haven't thought much about that part yet.
Received on 2004-12-13