On Thu, 9 Aug 2001, Adam Goode wrote: > Byte swapping audio in the kernel? From what I've heard, this is a no-no. > I'm pretty sure Linus and Alan Cox both agree that this is purely a > userspace task, and any attempt to move this into the kernel will be > met with great resistence.
Well, don't know what to tell you. It may not be the best, but it does work. > You may have better luck making sure that the driver correctly reports > that it cannot accept little-endian data, and then making sure that > your userspace programs (like xmms) properly check the driver's > capabilities and do the swapping themselves. 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. > I suggest any patches you provide work along these lines. 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. Derrik Pates | Sysadmin, Douglas School | #linuxOS on EFnet [EMAIL PROTECTED] | District (dsdk12.net) | #linuxOS on OPN