Been reading the thread with interest, and I finally have a moment to comment.
I was thinking about this several years ago when I had a lot of spare time on my hands and wanted to rethink and update the audio interface, and I think a lot of what you are suggesting sounds similar to the conclusions I had come to during the design phase. Comments inline. On Thu, Aug 13, 2009 at 10:00, Devon H. O'Dell<devon.od...@gmail.com> wrote: > 2009/8/12 Tim Newsham <news...@lava.net>: >>>>> - 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 I think this makes the most sense for the device driver interface. It's simple. > 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. I agree with this, too. Keep the interface simple and make the audioctl file smart based on the type of audio card you have. A complex file hierarchy just doesn't feel right to me. The simplest interface you can get away with is generally the most powerful. > 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). I haven't read up on sox, but I think the converter should be a file server sitting on top of /dev/audio. -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin
