>> Mostly because to do it correctly he argued that it has to be based >> on a callback design and that is not part of the alsa-lib. Hence >> JACK. >> > >Sorry, obligatory question, what's wrong with blocking calls? :)
Read the archives. We've been through this before. I'm not going through it again. >I think, in a sense, It's sad that most of us are programmers. >I find the "use the ARTS/ESD-JACK for whathver you need" >definitively not either an userfriendly or programmer friendly >approach. Why not learning from Takashi's approach with the sequencer >api? It could have been a separate lib too, but it wouldnt have become >so useful or popular. It also _rocks_ that even OSS programs can use >it via the emulation layer. Again, you don't even know the history of this stuff. The sequencer API was never a candidate to be separate from ALSA. It was originally designed by Frank van der Pol as ALSA's replacement for the clearly broken OSS sequencer API. The sequencer API can be used by OSS via emulation because it fundamentally attempts to do exactly the same thing. No suprise, since it was designed "around" the OSS one but with a much broader picture of how it should work and with the benefit of hindsight. This is quite different from what is needed to share and route audio data in a way that works for *both* low latency and "non-low" latency situations. Again, we've been over this over and over again and those discussions are archived. You seem totally unwilling to accept that we could have really thought about this. >Not to be pessimistic, but I think such thing is not going to happen. >Also I find the whole idea redundant. If JACK is easier and faster to >integrate then it should replace the ALSA api on that matter. >Developers, and specialy new ones, will allways support the official >api FIRST. Who declares "official" on Linux? There have been several people on this list who have affirmed that JACK is indeed easier and faster (and also more powerful) to develop with than ALSA, but you seem committed to ignoring such remarks. --p
