On Tue, Aug 05, 2003 at 06:46:39PM +0200, Ronald Bultje wrote: > Hey, > > On Tue, 2003-08-05 at 18:11, Ville Syrjälä wrote: > > On Tue, Aug 05, 2003 at 05:39:12PM +0200, Ronald Bultje wrote: > > > On Tue, 2003-08-05 at 16:57, Ville Syrjälä wrote: > > > > If anyone wants to write code that has a chance of working with all > > > > sourcards alsa-lib is a must. I see no point in making it optional. > > > > > > Why? > > > > Would you prefer that all application writers would have to worry about > > how the hardware expects the data? There are just too many different ways > > soundcards work to make this viable. > > The fact that an additional layer is needed to unify different hardware, > doesn't that mean that ALSA (kernel API) missed the big deal of being a > kernel API? I don't see how an API can overcome fundemental differences between various pieces of hardware. Conversions are required at some stage if the details are to be hidden from the user. > The kernel API is supposed to handle all this. If it doesn't, it sucks > and needs to be replaced. That's why v4l2 superseeded v4l1. v4l1 is > good, but v4l2 is simply better. And with v4l2 you still need format conversions. And that doesn't belong in the kernel like everyone here agrees. A conversion library will only succeed if enough people agree to use it. Everyone uses alsa-lib -> case closed. > > And the user has a lot of control on how alsa-lib does things. Take > > channel routing for example. There's no way each application would have a > > way to configure stuff like that. > > But the application still doesn't do that, but a different application > or configure file does. So I see no different in the kernel-API vs. > userspace lib approach. I don't quite follow but never mind. Let me just give you an example for what I mean: User has two multichannel cards and wants to combine a few channels from both cards to operate as a single unit. And at the same time he wants to keep a few channels from one card operating as another unit possibly for various GUI blings and other stuff. The GUI stuff will need format and sample rate conversions since the hardware is some monster with 32bit only support and the sample rate is locked 192kHz for the combined unit. And the user can re-route all of this by simply editing one configuration file. Or with a simple tool (if anyone should ever write one). I don't anyone wants this sort of stuff int the kernel. > > Also alsa-lib can do software mixing. > > It's nice, but it's bloat too. You don't have to use it. You can still bypass all of the fancy features. Ok I'll stop now with this off-topic stuff... -- Ville Syrjälä syrjala@xxxxxx http://www.sci.fi/~syrjala/
