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. 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
