On Thu, Aug 09, 2001 at 05:53:31PM -0600, Derrik Pates wrote: > > Well, don't know what to tell you. It may not be the best, but it does > work. >
I know, it's a tricky subject, and tends to start religious wars. Kernel vs. userspace, compatibility vs. cleaner design, etc. But Linus has spoken... > Well, this will break anything closed-source that wants to pass samples in > little-endian form (like the CivCTP demo). Also, conversion from 8 to 16 > bit samples, mono to stereo, and unsigned to signed is already in there. > The CPU usage associated with it seems to be negligible, which I'd say is > a good thing. > It also gives a argument towards using a standardized library/daemon, like esound or arts, which are designed to handle just these sorts of issues. (And just provides the slightest reminder that closed-source software is not going to be the absolute best supported form of software in the GNU/Linux world.) > Can that be done, though? Can the driver just not accept formats that the > hardware doesn't understand? If it can, is that even acceptable, > considering that (in this case) the hardware only knows one format (that > being 16-bit, signed, big-endian, stereo audio)? Besides, that means a lot > of people rewriting code, duplicating functionality (to reendianize their > audio if the driver decides it doesn't like the format), to support > hardware like PPC systems that don't understand many audio formats > natively, and are going to need help. > Sounds like the perfect place to introduce a userspace library, to fill this slack. Driver writers (especially Linus) like to minimize the amount of work done in the kernel, since a userspace solution is almost always cleaner, more secure, and easier to debug. Adam
