I agree wrt. "mp3". I'm considering the possibility of supporting
alaw, ulaw, pcm8, pcm16 in big/little and signed/unsigned formats,
and adpcm, using the hardware features...
Here's a complete list of audio formats that one can make hardware
either generate or accept. Where do you draw the line?
$ ffmpeg -formats | grep DEA | egrep -v "wmav|vorbis|flac"
DEA adpcm_4xm
DEA adpcm_adx
DEA adpcm_ct
[...]
Draw the line at what the hardware can be told to decode
with a flip of a register? The driver interface can easily
accomodate arbitrary encoding names (see inferno's driver
for an example). The rest is just mapping strings to register
values. With the appropriate API, supporting 30 audio formats
is hardly harder than supporting 3....
One thing that strikes me is that if the device interface is
designed in a flexible way that allows for arbitrary codings, then
it will be easy to layer a userland driver on top of it that
extends the API with more encodings that arent supported in hardware.
If the interface isnt flexible in this way, then a separate
interface will have to be made for such a userland driver...
I'm not sure what the value of unifying those two interface is...
Roman.
Tim Newsham
http://www.thenewsh.com/~newsham/
