Re: Trashed audio out on Tumbler (iBook audio device) when samples are little endian - fixing it now
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
Reply to: