Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Lee Revell <rlrevell@joe-job.com>]

On Thu, 2005-02-03 at 22:41 +0100, Ingo Molnar wrote:
> > 
> > It's clever that they do that, but additional control is needed in the
> > future. jackd isn't the most sophisticate media app on this planet (not
> > too much of an insult :)) [...]
> 
> i think you are underestimating Jack - it is easily amongst the most
> sophisticated audio frameworks in existence, and it certainly has one of
> the most robust designs. Just shop around on google for Jack-based audio
> applications. What i'd love to see is more integration (and cooperation)
> between the audio frameworks of desktop projects (KDE, Gnome) and Jack.

JACK was not designed as a general purpose sound server, it's main goals
were sample accurate synchronization and low latency which a general
purpose desktop sound server does not need.  But, JACK does provide a
superset of the needed functionality - if you can do low latency you
should be able to handle high latency/buffering jut as easily, and
sample accurate sync will not break apps that don't need it.

The main obstacle to JACK-ifying everything is that it requires audio
apps to conform to the callback based JACK programming model.
JACK-ifying a complex app that expects to be able to read and write
audio whenever it wants to amounts to a complete rewrite.  But simpler
apps like XMMS can use a layer on top of JACK like the bio2jack library.

Anyway, Linspire (formerly L*nd*ws, formerly ...) will be using JACK as
the sound server in their next release.  And GNOME is moving to
gstreamer which can use JACK as a backend.

Bill has a good point, in that JACK is really just scratching the
surface as far as the myriad possibilities that good realtime support
will open up.  Apps like mplayer that use a broken single threaded
design which completely ignores the RT constraint inherent in AV
playback will be corrected for example.

Lee