So what is preventing us from taking CoreAudio-like path and reworking the way audio is handled OS-wide? Is this just a gargantuan task or is it just lack of interest? No one said that we need to stick to the OSS standard established way before anyone even considered Linux as a multimedia workstation.
Maybe we could build a new architecture based around Alsa which, according to what you have said, should reach its final stage rather soon. Then we would not require the redundant re-implementation of sound-sharing daemons, which by their mere existence add to the latency issue. I understand what you are saying but that still seems to me a roundabout way to solving the core of the problem. My thought is if we already have a capability of low-latency interaction between apps via JACK, we should rework it so that JACK becomes a powerful kernel daemon which would be capable of routing signal however we wanted it independent of apps (and maybe allowing extremely low latency to be routed through when requested [maybe by having a priority stuff established, so that the every-day blips and beeps which are used for desktop sounds can use low priority stuff, or can even be pushed around if needed], i.e. in the case of Ardour). On the other hand, you have mentioned alsa-server. I must admit I do not have much knowledge regarding this one. Is this server capable of providing daemon-like audio resource sharing and keeping latency low? If so, maybe this should be the core framework for the new daemon? If there is a better solution to this problem than what was originally established by OSS, shouldn't we learn from our own mistakes and other's successes (i.e. core audio and BeOs) and rework the way audio is handled in Linux? Isn't the BeOS at this point open source? Maybe we could hack their code and use that as a foundation? It seems to me that OSS's original conception of audio on Unix machines was to provide limited audio capabilities (i.e. so that computer can play blips and beeps when needed), so if that is the case why are we still trying to push this architecture way beyond its limits? If our existing ways of handling audio resources are outdated or inefficient, we should then reconsider the foundation of our audio architecture and improve upon it based on what we have learned? Could you please tell me how hard would it be to rework the way audio is handled, while preserving existing compatibility with esd and artsd-based apps, and on top of that providing JACK-like efficiency (with priority managing capability)? I am still not convinced that avoiding the heart of the problem by providing roundabout solutions will get us far. If we want to have Linux as an audio powerhouse, as well as provide efficient environment for development of audio-related applications, maybe we need to get rid of the elements that are stalling our progress... Interesting comments. Keep 'em coming :-) Ico
