From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Date: Wed, 12 Aug 2009 19:16:14 -0700 From: Roman Shaposhnik In-reply-to: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <97C5540D-6FE2-4587-9F05-8799E0056622@sun.com> References: <38fa4d234fa7ff8613123fe9a6921943@quanstro.net> <13426df10908112014y49c5a89dpd616ce4529c1efe1@mail.gmail.com> Subject: Re: [9fans] audio standards -- too many to choose from Topicbox-Message-UUID: 44dfe6e4-ead5-11e9-9d60-3106f5b1d025 On Aug 12, 2009, at 1:28 AM, Tim Newsham wrote: >>> I agree wrt. "mp3". I'm considering the possibility of supporting >>> alaw, ulaw, pcm8, pcm16 in big/little and signed/unsigned formats, >>> and adpcm, using the hardware features... >> >> >> Here's a complete list of audio formats that one can make hardware >> either generate or accept. Where do you draw the line? >> $ ffmpeg -formats | grep DEA | egrep -v "wmav|vorbis|flac" >> DEA adpcm_4xm >> DEA adpcm_adx >> DEA adpcm_ct > [...] > > Draw the line at what the hardware can be told to decode > with a flip of a register? Pretty much all of the above. > The driver interface can easily > accomodate arbitrary encoding names (see inferno's driver > for an example). The rest is just mapping strings to register > values. With the appropriate API, supporting 30 audio formats > is hardly harder than supporting 3.... My list was only there to try and prove the point that Russ has made -- pick a most common format and stick with it. Convert everything else into it. Forget about the fact that hardware can/could do gazillion variations. At least forget about it for the time being while you're getting basics right. > One thing that strikes me is that if the device interface is > designed in a flexible way that allows for arbitrary codings, then > it will be easy to layer a userland driver on top of it that > extends the API with more encodings that arent supported in hardware. > If the interface isnt flexible in this way, then a separate > interface will have to be made for such a userland driver... > I'm not sure what the value of unifying those two interface is... I don't think I buy this point of view. Gratuitous flexibility is not something Plan 9 is known for, nor should it. IMHO. Thanks, Roman.