i didn't mean translating from one /dev/audio to the next. i ment dealing with azalia audio vs. ac97 vs. soundblaster. and ogg/vorbis vs. mp3 vs pem vs. *law.
I agree here. I envision a separate codec server that sits on top of an audio server and encapsulates a bunch of this stuff. It would be nice if it was practical to "cat foo.mp3 >/dev/codec/mp3" or something like that.. I haven't really thought this through much, just daydreaming this feature...
i would be interested in a solid implementation. i haven't yet spent any serious time looking at the various ac'97 drivers but they didn't seem to me to go quite far enough in defining an audio universe. that's one thing that draw(2) does do that i would hope audio would do as well.
I'm not familiar with what ac97 provides. Can you describe a little what the features are and what you think an interface should be like? Here's a brief rundown of what I was thinking about, somewhat based on the inferno driver: $ cat /dev/audioctl enc pcm8 pcm16le pcmu16be ulaw rate 44100 8000 11025 22050 chans 2 1 meaning that the device is currently in pcm8 at 44.1khz and 2 channels (stereo). (Inferno's driver would have said enc "pcm" with bits "8" instead of saying "pcm8", but I feel that separating out bits and possibly endian for "pcm" adds complication since the encoding "pcm-16-unsigned" isnt really a separable thing). $ echo "rate 11025" >/dev/audioctl $ echo "chans 1" >/dev/audioctl $ cat /dev/audioctl enc pcm8 pcm16le pcmu16be ulaw rate 11025 44100 8000 22050 44100 chans 1 2 $ dd if=/dev/audio of=sound bs=4096 now we have 4k samples of 11khz mono audio in "sound" additionally it might be useful to support some of the stat features from usbaudio or plan9 audio(3), such as the ability to figure out the dma size, how much data is buffered, and the timing associated with samples being read.
- erik
Tim Newsham http://www.thenewsh.com/~newsham/
