KDE4 MM, a view from usability and general applicaiton development

[Ronald S. Bultje]

On Wed, 2004-09-08 at 21:56, Arnold Krille wrote:
> On Wednesday 08 September 2004 21:26, Ronald S. Bultje wrote:
> > On Wed, 2004-09-08 at 21:13, Arnold Krille wrote:
> > > And afaik if a system is optimized for doing video and audio in sync
> > > (where latency is irrelevant as long as both act the same time), you have
> > > so much work to do in your process, that its _very_ likely you don't have
> > > the time to do 5 or more process-switches for audio and some for for the
> > > other programs running and having a over-all-latency of 3-5ms.
> > But there are no process switches needed for this. You simply have a
> > central clock that one element (the master clock, mostly audio element)
> > exposes to the other elements, and the other elements wait for this
> > clock for playback of their video frames. That is all. There is no
> > process switching, sleep, conditional waiting or anything needed. Some
> > implementations don't even require thread locking (which is just for
> > theoretical thread safety; in practice, this doesn't hurt performance at
> > all).
> 
> Yes there are process switchings: From your master-clock to all the other apps 
> doing video and audio. And this are a lot of switches...

No there are not. ;). There's no process switching involved here with
the clock, each task (video, audio) runs in its own process and access
the clock in its own process. There's just the process switches (in the
kernel) between the actual video data processing and audio data
processing. Those run concurrently, though.

For pro-audio, there's no video and thus only one process. Latency can't
get much lower.

Note, we're not perfect. I'm sure scheduling can still be improved, and
several elements do things that are officially not allowed in RT, such
as resource allocation (particularly malloc()'ing buffers). But the
basics are there. Several audio elements comply to many RT wishes
(including no memory allocations in the main loop, no sleeps or waits,
etc.).

> And there can only be one app accessing the soundcard (despite you use dmix 
> but then you don't get mixing (the real mixing with changing the volume 
> dynamicly (Yes, I love brackets! (I am the bracket master...)))).
> 
> And we are talking about (semi-)professional audio where latency has to be 
> _very_ low. And I know that Jack did a very great job of keeping a lot of 
> apps in sync for realtime audio. And its very easy to break it by having to 
> swap in one process (may it be related to audio or just the kicker of your 
> desktop)...

If the user wishes to run an artsd/esd app together with his ultra-1337
pro-audio app and complains to me about latency, I really can't do
anything but send him to a psychiatrist. That's pebkac, you know? :).

Ronald

-- 
Ronald S. Bultje <rbultje at ronald.bitfreak.net>