From: Dave Chapman <dave_at_dchapman.com>
Date: Tue, 14 Dec 2004 12:11:58 +0000

Linus Nielsen Feltzing wrote:
>> 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.

OK, I'm happy to do that.

I'm basically thinking along the following lines:

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

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

This API will basically be the same as the functions implemented in
firmware/mpeg.c, but applicable to non-MPEG files and non-ID3 metadata
as well.

3) The audio API would include a function called (for example) add_codec
which would probably pass a structure of function pointers as the
argument. These functions (and any functions needed to be exported by
Rockbox to the codec plugins) would provide the "codec API".

In addition to audio playback (and recording), there is also a need for
a "Mixer API" to control volume and any other special effects the
hardware supports. Potentially, the iRiver could include a software
mixer to manipulate the decoded PCM audio but that may be thinking too
far ahead.

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.

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.


All of this implies quite major changes to the whole of rockbox - but I
can't see how that can be avoided if we want all the existing code to be
compatible with any audio file format. Hopefully most of the changes
will simply be renaming functions to a more generic equivalent. The
rest would be hidden from the Archos versions of rockbox inside
HW_SUPPORTS_CODECS #ifdefs.

Regards,

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