>[snip] >> what you're missing is that high end applications need *two* things: >> >> 1) low latency >> 2) synchronous execution >> >> the latter is extremely important so that different elements in a >> system do not drift in and out of sync with each other at any time. >> >If it is possible to have an audio server that would satisfy the requirements >of high end applications it should also suit applications that just want >sound to add to the ui.
thats fine. the problem is this: if you require that the "add sound to the UI" apps use the same API as the "high end ones", people writing the former category of apps have to adapt to a callback-like model. they will likely find this quite hard. If instead, you allow them to use ALSA's HAL-like model (which can be done reasonably easily by using something like the ALSA "share" server to mediate between ALSA and JACK), then you continue to have two different APIs with all the problems that implies. >> i don't mean to sound harsh, but this is naive. there is no agreement >> among any of these groups on what they want. ALSA *is* a standardized >> API that is equivalent, roughly speaking, to the HAL layer in Apple's >> CoreAudio. if people are willing to write to a HAL layer, ALSA is the >> "basic standardized API" you're describing. but IMHO, thats not enough. >> >I'm curious as to what you would propose be done about the current state of >sound under linux. I'm certainly not the only one willing to help work(code >etc) to reach the goal of making a more unified and more suitable sound >architecture under linux. Something should be done sooner than later as from >a deverloper standpoint things are quite confusing. as i've said several times: i don't think there is much that can be done except producing working systems with such impressive performance and capabilities that people recognize them for what they are, and decide to start using them. we cannot make things more unified under linux - just take a look at GNOME and KDE: there is absolutely nothing to stop the same kind of fracture in the audio realm (and in fact, developers of these environments are contributing to that very thing). the particular system that i am working on (with help from kai, andy wingo, jeremy hall, richard guenther and others) is JACK, and if you want to help out, please do. but as i said before, the API JACK presents is unfamiliar to most people working with audio under Linux, and there is likely to be much resistance to it, despite the many benefits and enhanced portability it offers. >Interesting. I'm unfamiliar with CoreAudio although if it is technically >superior and fullfills requirements then we should look to mirror its >capabilities. that's what JACK is all about (except that the ideas behind JACK predate CoreAudio's appearance). CoreAudio has been measured as technically superior in terms of latency to any other audio API. JACK (with ALSA as the HAL layer) came second. --p _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
