2009/8/13 James Tomaschke <ja...@orcasystems.com>: > erik quanstrom wrote: > >>> I don't see the complexity, the interface merely needs to allow device >>> drivers to provide the information such as "I support x y z", the >>> application can query a "features" file, select a format and write back >>> through the interface configuring the hardware. The interface need not >>> have any predetermined knowledge of available formats. The only issue >>> would be for each device driver to agree to call the same format by the >>> same name, "s8 s16le s24be". >> >> i think you're ignoring the complexity. suppose we wish to >> support 10 formats. suppose that i have devices that support >> all 10 formats. then there are 90 different conversions to do >> to fill in the gaps. now suppose that we pick a format. then >> we need to write 10 conversions. also each driver potentially >> needs 1 conversion. if we want to write things like audio >> mixers or whatnot in software, we only need to support 1 input >> and 1 output format. > It's a matter of kernelspace vs userspace and freedom. > > Nothing I have proposed prevents you from using a single format. > Nothing I have proposed requires you to implement N formats or > conversions. This is because I allow for your freedom to do so in > userspace. > > Rather, your suggestion of forcing a single format, prevents my > applications from using other formats, and it requires I implement > conversions. This is because you limit freedom by placing a simple > interface into kernelspace.
This is the silliest thing I've seen posted in this thread. No offense intended, but if you choose the highest available sample size and bit rate available to the card, you are not limiting anybody: the limitation becomes the hardware. If that's an issue, get really ridiculously high quality analog devices, and stop being so anal about your perfect ears. --dho
