Steve Harris <S.W.Harris@xxxxxxxxxxxxxxx> writes: > > 2.)would jack be as stable and powerfull than as it is when optimized > > for pro-Apps only ? > > No - adding things like sample format negotiation and sample rate > conversion would seriously hurt JACK. JACK developers have been trying for a long time to explain these issues to the many people who want to use it for everything. It works great for ardour, so why not do "beeps" and "tadas" that way? The answer is that JACK achieves low latency by placing non-negotiable realtime deadlines on its clients. They must make a serious effort to meet these requirements lest they get kicked out by jackd, the JACK server daemon. Consumer sound really needs an extra layer of buffering, format conversion, and hand-holding between it and jackd. Arts is one solution for that problem. Having never used it I can't speak about its strengths or weaknesses. But, it is integrated into the KDE desktop, which is valuable in its own right. The current problems with artsd and jackd occur when a user tries to start jackd but artsd is already running, so the audio device is busy. Hopefully, the KDE developers will configure things so that this works smoothly. I do wonder how they will do it, though. Will they expect jackd to be running all the time? Most users don't run it that way today. Perhaps by the time KDE 3.3 comes out jackd will have evolved a config file so it can start automatically as needed. -- joq
