>You are speaking about higher abstraction level on the one hand and on >the other, you want to control everything. But okay, I see the potential.
No, I only mentioned the library of conversion functions because some people will feel a need for them in a JACK-like system. Personally, all my applications will continue to be sample-rate agnostic and use normalized floating point format for samples, and I'd prefer that most people did that. I want my apps to be mostly neutral slaves of a JACK server+driver combination. >We can easily offer the simple callback plugin system also in alsa-lib. >I'll integrate LADSPA to our plugin system ASAP to make an example. That wasn't my point at all. I don't think you get it. Neither you nor Abramo have once demonstrated any appreciation for the way that other plugin systems or CoreAudio work, nor the overall design they create. You keep telling us that alsa-lib can be made to do this, alsa-lib can be made to do that; its completely obvious from both the code and the historical record that it was never designed with this kind of model in mind. The basic model for how audio in ALSA operates is derived from OSS's adherence to the basic Unix model of open/read/ioctl/write/close. Its been enormously improved (and partially hidden) in ALSA, but thats still the underlying architecture. IMHO the evidence is clear that this is not the correct model for a general purpose application audio API, but you continue to insist that you can coerce alsa-lib into doing the things we're talking about. You probably can, but I don't think that means you should. I'll work on JACK, you work on making the ALSA "plugin" system work the way you think it should, and I'll try to shut up. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
