> Instead of writing translators I'd rather pick a single convention > that seems the most suitable and fixup the other implementations > and clients to fall in line with those conventions. My biggest > question is "is it worth my time?" If I spend time unifying > the various implementations, will they be accepted back into > the mainline or will it be viewed as unnecessary churn... > How much do people even care about the audio drivers and they're > interfaces at the present time?
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 might be out-of-step. but i care about audio drivers. there hasn't been the time to tackle that problem, though. 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. since neither of the ac'97 drivers are in the distribution, i don't think you can cause more churn than there is already. basically, the way to get plan 9 audio right now is to use (a) ancient hardware (b) a nonstandard kernel (c) drawterm. i don't want to short change 9vx, but i don't know about it off the top of my head. sounds like a cool project. - erik
