Roman Shaposhnik wrote: > On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote: >>> Here's a complete list of audio formats that one can make hardware >>> either generate or accept. Where do you draw the line? This is incorrect, you don't "make hardware" do anything, the software layer that sits on top of the hardware does this. The SB16 hardware does not support ADPCM and it never will.
> 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. By this logic, I need to have my application to convert CDROM-XA ADPCM audio from a device into PCM just to talk to an interface, which in turn must convert it back into ADPCM to play it back because the DMA transfers to the audio hardware buffer require ADPCM. >> 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. Why does this idea deserves a "gratuitous" label? Preventing an application from communicating to the hardware in a native format is complete lack of flexibility. If you do not care about native hardware formats, why choose PCM over ADPCM as a transport? ADPCM is ~3/4 the size of PCM in terms of bandwidth. MPEG audio and probably most telephony codecs use ADPCM, why consider the 1980 RedBook PCM as the holy audio format?
