2009/8/12 Tim Newsham <[email protected]>: >>>> - What software exists for each of these formats? >> >> If you are asking about non Plan9 software I'd start with >> ffmpeg. >> >>>> - Which format is the most "popular"? >> >> I don't think I understand the question. > > Sorry, let me rephrase: > - Of the different audio driver interface designs > (audio(3), usb(4) and inferno usb(3)) which software > (p9 and limbo) uses each? > - Which of these interfaces is used the most?
I don't know which is used the most, but I don't think the Plan 9 ones of them make particularly good sense to support multiple input formats to multiple output formats. sox was mentioned here recently, and is a great utility for doing the conversion. If we want a generic, reusable audio layer, to *me* the Inferno one is best with: audio audioctl It doesn't make sense to export files for volumes, codes, channels, and other settings to me. This is because (at least with HDA cards) you would end up with 5 bajillion files for controlling volume on each individual channel. You'd end up with another file for reading/writing codec settings. You'd end up with a file saying whether you preferred digital output or analog output. OSS relies heavily on ioctls for setting these things, but for good reason. In our case, a standardized set of strings for the ctl file seems best to me. If I want to change master volume, echo master 255.255 > /dev/audioctl. If I want to set digital out, echo output channel digital > /dev/audioctl. etc. A more spread out filesystem would make the ctl handler smaller, but would not reduce the amount of code needed to support mixers / codecs / channels / whatnot (In fact, you'd just have more code because you'd have to have functions for reading/writing those files). Also, then you just need to come up with strings -- you're just bit frobbing these things, and more complicated filesystem hierarchy doesn't help explain it any better. echo 255 > /dev/audio/mixer/channel/master/right; echo 255 > /dev/audio/mixer/channel/master/left; just seems obtuse, and, as I said, it's just adding more redundant code anyway. To then play sound, you would probably have a sox-like converter sitting on top of that (maybe even on top of /dev/audio?) that takes input of a certain format and does either minimal conversion (i.e. a card that supports XA ADPCM taking input from a playstation 2 sound file not having any conversion at all, WAV going to the proper byte-order PCM with the header stripped off, etc), or highest resolution audio available (e.g. 5.1 flac getting converted to whatever codec supports 5.1 audio). Thoughts? --dho
