Re: [LAD] Any package builders here?

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <paul@...>
Cc: <linux-audio-dev@...>
Date: Wednesday, June 1, 2011 - 1:11 pm

--_5b1a3595-51b7-4db4-9a99-f58b5b02daa7_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> Paul Davis wrote:

The argument is that rendering images=2C a part of the GUI=2C also requires=
chewing
up a lot of CPU. These processes aren't involved in lots of disk IO=2C they=
can be
manipulating images with either 2D or 3D transforms - as I said=2C it is pr=
etty=20
similar processes to DSP=2C it is intensive.=20

The time slicing scheduler gives preference to runnable processes that are =
not=20
using all of the CPU that is given to them and since the image manipulation=
code
is doing exactly that when elements of the image are being moved then its p=
riority=20
pushes it down the list of runnable process - it may have to wait longer to=
carry on=20
the rendering code.

There are many aspects to a responsive system: you seem to be arguing that =
the
only relevant one is the audio processing (which includes the disk subsyste=
m). All
I am saying is that when you use the mouse to pick up an element in the GUI=
and
you move it that you then also want to see it move. RT scheduling and big b=
uffers
are the tools you use to maintain the audible components and renice is almo=
st the=20
only sad little thing available for all else.=20

> which is why ardour's default disk i/o buffers are *FIVE SECONDS* long (w=
e=20

Ardours disk thread is sched_other. When you wait seconds for IO which fina=
lly
arrives then your process is pretty much guaranteed=2C by the scheduler=2C =
to be the
next process to take the free CPU as your priority improves as your waiting=
time
goes up. A number crunching GUI does not have this benefit since it has not=
sat
around waiting for the system to do something. Applying a renice will move =
it
up the queue (although even at renice -20 it would not pre-empt the typical=
=20
priority of this disk process).

> SCHED_OTHER are targetting console-driven applications that do varying

I was not even considering the effects of time scheduled actions in a GUI=
=2C simply=20
tracking the interactions of the user with their interface when the system =
is under
stress.

I think we may have mixed the conversation. Ralf asked if this option shoul=
d even
be in the limits configuration. My answer=2C offlist=2C was that there were=
some potential
uses and that since you can already hose an otherwise perfect system by giv=
ing a user=20
permission to access to RT limits that there is no adverse effect of keepin=
g this one.

If there are good arguments not to have this as a limit for the audio group=
then have
the distributions remove it=2C by all means. I don't see the negative side =
it being provided=2C
it remains a tuning tool.

> Robin Gareus wrote:

I would have expected most of them to implement but that is just an opinion=
=2C I am not=20
big on having to rely on other libraries for features that I consider cruci=
al. As stated above=2C=20
user experience is defined by system response=2C that includes the audio an=
d the video.=20
Bristol has these as separated processes and this is one of very few ways t=
o control the=20
its GUI CPU profile.=20

> ..and how many pro-audio users do use this software [...]

I would not contest that. I am not sure how rtprio and having renice in the=
limits config
is really related to jack though.

Regards=2C nick
=

--_5b1a3595-51b7-4db4-9a99-f58b5b02daa7_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

&gt=3B Paul Davis wrote:&gt=3B what are those arguments? The ar=
gument is that rendering images=2C a part of the GUI=2C also requires chewi=
ngup a lot of CPU. These processes aren't involved in lots of disk IO=
=2C they can bemanipulating images with either 2D or 3D transforms - as=
I said=2C it is pretty similar processes to DSP=2C it is intensive. The time slicing scheduler gives preference to runnable processes tha=
t are not using all of the CPU that is given to them and since the imag=
e manipulation codeis doing exactly that when elements of the image are=
being moved then its priority pushes it down the list of runnable proc=
ess - it may have to wait longer to carry on the rendering code.There are many aspects to a responsive system: you seem to be arguing that=
theonly relevant one is the audio processing (which includes the disk =
subsystem). AllI am saying is that when you use the mouse to pick up an=
element in the GUI andyou move it that you then also want to see it mo=
ve. RT scheduling and big buffersare the tools you use to maintain the =
audible components and renice is almost the only sad little thing avail=
able for all else. &gt=3B which is why ardour's default disk i/o bu=
ffers are *FIVE SECONDS* long (we &gt=3B really have seen delays of thi=
s length when reading from disk!).Ardours disk thread is sched_othe=
r. When you wait seconds for IO which finallyarrives then your process =
is pretty much guaranteed=2C by the scheduler=2C to be thenext process =
to take the free CPU as your priority improves as your waiting timegoes=
up. A number crunching GUI does not have this benefit since it has not sat=
around waiting for the system to do something. Applying a renice will m=
ove itup the queue (although even at renice -20 it would not pre-empt t=
he typical priority of this disk process).&gt=3B SCHED_OTHER ar=
e targetting console-driven applications that do varying&gt=3B balances=
of disk i/o=2C computation and user input/output. they really&gt=3B do=
n't address the situation of an app that needs to redraw with a&gt=3B r=
elatively fixed interval on screen=2C nor do they provide any actual&gt=
=3B scheduling guarantees=2C I was not even considering the effects=
of time scheduled actions in a GUI=2C simply tracking the interactions=
of the user with their interface when the system is understress.I think we may have mixed the conversation. Ralf asked if this option sho=
uld evenbe in the limits configuration. My answer=2C offlist=2C was tha=
t there were some potentialuses and that since you can already hose an =
otherwise perfect system by giving a user permission to access to RT li=
mits that there is no adverse effect of keeping this one.If there a=
re good arguments not to have this as a limit for the audio group then have=
the distributions remove it=2C by all means. I don't see the negative s=
ide it being provided=2Cit remains a tuning tool.&gt=3B Robin G=
areus wrote:&gt=3B How many audio apps support 'rtprio' directly (witho=
ut JACK)? I would have expected most of them to implement but that =
is just an opinion=2C I am not big on having to rely on other libraries=
for features that I consider crucial. As stated above=2C user experien=
ce is defined by system response=2C that includes the audio and the video. =
Bristol has these as separated processes and this is one of very few wa=
ys to control the its GUI CPU profile. &gt=3B ..and how many pr=
o-audio users do use this software [...]&gt=3B I bet the number is zero=
.I would not contest that. I am not sure how rtprio and having reni=
ce in the limits configis really related to jack though.Regards=
=2C nick
=

--_5b1a3595-51b7-4db4-9a99-f58b5b02daa7_--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 9:50 am)
Re: [LAD] Any package builders here?, Fernando Lopez-Lezcano, (Wed Jun 1, 5:14 pm)
Re: [LAD] Any package builders here?, Robin Gareus, (Wed Jun 1, 12:40 pm)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 3:38 pm)
Re: [LAD] Any package builders here?, Paul Davis, (Wed Jun 1, 11:27 am)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 4:10 pm)
Re: [LAD] Any package builders here?, David Robillard, (Wed Jun 1, 4:56 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 4:38 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 11:49 am)
Re: [LAD] Any package builders here?, Dominique Michel, (Wed Jun 1, 4:17 pm)
Re: [LAD] Any package builders here?, Ralf Mardorf, (Wed Jun 1, 4:24 pm)
Re: [LAD] Any package builders here?, Paul Davis, (Wed Jun 1, 12:06 pm)
Re: [LAD] Any package builders here?, David Robillard, (Wed Jun 1, 3:06 pm)
Re: [LAD] Any package builders here?, Nick Copeland, (Wed Jun 1, 1:11 pm)