On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote:
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?
Pretty much all of the above.
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....
My list was only there to try and prove the point that Russ has
made -- pick a most common format and stick with it. Convert
everything else into it. Forget about the fact that hardware
can/could do gazillion variations. At least forget about it for
the time being while you're getting basics right.
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...
I don't think I buy this point of view. Gratuitous flexibility is not
something Plan 9 is known for, nor should it. IMHO.
Thanks,
Roman.
