From alsa-devel-owner@alsa.jcu.cz  Tue Jan 12 18:51:45 1999
Received: from nic.funet.fi (nic.funet.fi [128.214.248.6])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA08044
	for <alsa-devel@alsa.jcu.cz>; Tue, 12 Jan 1999 18:50:26 +0100
Received: from localhost (user: 'kouhia', uid#241) by nic.funet.fi id <2970-2279>; Tue, 12 Jan 1999 19:50:10 +0200
From: Juhana Sadeharju <kouhia@nic.funet.fi>
To: alsa-devel@alsa.jcu.cz, linux-audio-dev@ginette.musique.umontreal.ca
In-reply-to: <01b901be3e31$c59be340$47010180@pcbg> (golinvaux@benjamin.net)
Subject: Re: Linux scheduler issues.
Message-Id: <19990112175014Z2970-2279+2105@nic.funet.fi>
Date: 	Tue, 12 Jan 1999 19:50:10 +0200
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

>From:	"Benjamin GOLINVAUX" <golinvaux@benjamin.net>
>
>I only run my process and with some good HD tweaking (hdparms ?) but I'd
>like to have the scheduler allow me to do network or run an xterm but
>preserving the cpu power needed by my app (the remaining cpu power would
>then be shared among the other apps).. I clearly prefer this approach...

We could discuss about these issues on linux-audio-dev mailing list
as it is already suggested. But if we go for other mailing list,
it should be a separate realtime-audio mailing list. It should not be
related to OMT or any other projects. I think linux-audio-dev is general
mailing list and discussions about realtime audio goes fine there.

I have now posted this to linux-audio-dev too.

>Maybe we could start some mailing lists... One for drivers, another for
>scheduling, real-time os and so on... What do you think about it ?

All three should be just one mailing list in the context we have here.
ALSA is ok for talk on specially drivers (since ALSA in GNU; OSS is not).

We should discuss about how to modify Linux or extend Linux such that
it is suitable for audio applications. Then our proposition could be
discussed in existing general scheduling etc. mailing lists.

It was very interesting idea of running a second, realtime OS in one
process which is running alone but it has problems as already described.
I think my proposition about running selected processes at predefined
ticks is worth of discussing too. The point is: lets not limit our
discussion to one particular model. I would have comments about the ticks
system from people who know about these things even they are strongly
toward some other system. Thank you.

Is there somewhere in the net a good tutorial for OS scheduling and so on?

Hmm.. is it KSynth which runs a process as realtime process (in RTLinux?),
examines when the process' cpu load is over %90 and, in such case, freezes
the process to allow other processes to work. Any problems in that approach?

Yours,

Juhana

