From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Sat, 15 Aug 2009 05:24:01 +0800." <140e7ec30908141424l425e1da5kaa16d0a521f810fb@mail.gmail.com> References: <38fa4d234fa7ff8613123fe9a6921943@quanstro.net> <13426df10908112014y49c5a89dpd616ce4529c1efe1@mail.gmail.com> <140e7ec30908141424l425e1da5kaa16d0a521f810fb@mail.gmail.com> From: Bakul Shah Date: Fri, 14 Aug 2009 15:05:07 -0700 Message-Id: <20090814220507.F09795B30@mail.bitblocks.com> Subject: Re: [9fans] audio standards -- too many to choose from Topicbox-Message-UUID: 4a86ae34-ead5-11e9-9d60-3106f5b1d025 On Sat, 15 Aug 2009 05:24:01 +0800 sqweek wrote: > On 12/08/2009, Tim Newsham 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.