On Sat, 15 Aug 2009 05:24:01 +0800 sqweek <[email protected]> wrote: > On 12/08/2009, Tim Newsham <[email protected]> wrote: > > Draw the line at what the hardware can be told to decode > > with a flip of a register? The driver interface can easily > > accomodate arbitrary encoding names (see inferno's driver > > for an example). > > One thing I haven't seen mentioned (perhaps because I misunderstand) > is the added state that comes from allowing multiple formats. > Actually, I think this problem exists with the current interface > already - say I have a program playing music at 44kHz and then I get > an email or something that I've set up to cause an aural alert, but > the program that does that wants to work at 22kHz. This sort of > interaction sounds bad enough to me, I don't even want to think about > what it would sound like if the music was in mp3 and the alert changed > the kernel format to wav.
The mixer would have to be smart. > I guess this is where mixerfs and the like enter the picture, but > I've come to think of the kernel as a hardware multiplexer so I'm > liking the idea of having the kernel support multiple formats. > Then again, I also respect the argument that the kernel is not a > hardware multiplexer but a hardware abstractor - doesn't matter what's > down there the kernel provides the same interface. From this point of > view the simple approach is compelling, have /dev/audio exclusive > write to avoid the above sort of interaction and mix in userspace (or > is there still playback/recording sample rate interaction?). I think > everyone agrees it doesn't make sense to have an mp3 decoder > in-kernel... > -sqweek A decoder is just a resource (like a mouse, keyboard, disk, network interface etc.). If h/w provides an mp3 decoder it would be nice to be able to use it. One idea is to have a devicename for each format/samplerate. Some would be backed by h/w, some provided solely by s/w. Basically you need an ability to interpose some sort of "stream" module to create a network.
