Re: Polypaudio for Gnome 2.10, the next steps

[Havoc Pennington <hp redhat com>]

On Wed, 2004-11-24 at 15:46 +0000, Alan Cox wrote:
> 
> > That mixing is no longer done in hardware but has been punted to the
> > host system for low cost cards feels like a driver layer issue, not
> > something that should be solved by an intermediary sound API. To give a
> > crude analogy, this feels like proposing that the host CPU bits for
> > Winmodem support should be handled in the application layer.
> 
> Correct, and that happens to be the right model for Winmodems too. You
> don't want stuff in the kernel when you can avoid it.

You're missing the point I think; for most of the world there are three
layers:

   - kernel
   - APIs/libraries
   - applications

For kernel developers there's only kernelspace/userspace. But those of
us in userspace don't care about the kernel, only about the
APIs/libraries (which may end up using the kernel, but it shouldn't
matter to applications).

This is the same point we have made repeatedly in the context of
removable media handling, wireless handling, and many other areas; we
absolutely cannot have "if (specific hardware device)" code in
individual applications because then you have to change N places to add
new device support. Such code should be only in some kind of single
systemwide place hidden behind an API.

ALSA did get this thing right, they take responsibility for the whole
API under the ALSA project umbrella, instead of just doing the kernel
part and saying "we guess the rest can be magically solved by someone in
userspace even thought the kernel part isn't designed properly to make
things work from top to bottom" ;-)

Of course the ALSA API apparently doesn't even support setting the
volume, but that's another flamefest ;-)

So by "driver layer" vs. "application layer" what I take Seth to mean is
that driver layer = "where you special case particular hardware devices"
and application layer = "where you use the generic API (though that API
may have ability to query capabilities and otherwise adapt to hardware
limitations, it would do so generically)"

Nobody writing apps cares whether an API is implemented in the kernel or
not, only that the API is at the right abstraction level: we don't want
"drivers" - i.e. any sort of specific-device-model handling - in the
apps.

Havoc