7 Dec
2004
7 Dec
'04
9:27 a.m.
On tis, 2004-12-07 at 13:07 +0100, Artem Baguinski wrote:
I'm a bit puzzled with this one thing about low
latency and jack: real
time bits can't do IO, but don't you get latency between say me
pressing some button and sound doing click? there's no garanty the not
realtime part of the application will run often enough to read the
input device, no?
Is this a GUI button or a MIDI button?
MIDI buttons/sliders do not need to have any noticeable latency if the
MIDI-thread is run at the (near?) same priority as jack. Although the
thread has high priority, it is mostly idle and will consume next to no
CPU.
Suppose JACK consumes 90% of your CPU, you will have 10% left to do your
MIDI IO, which is plenty for processing a handful of bytes.
GUI buttons on the othe hand are expensive to repaint by nature, and the
cost depends on what kind of eye-candy your installed GUI-theme will
use.
just recently some heavy process started when i was
fulling around
with some soft synths [i know that shouldn't be happening, but i just
recently switched distros and I haven't learned enough to write
dont-bother-me script to switch all potential sources of disturbance]
and the GUI of the soft synth became quite irresponsive, while audio
went on without any glitches - that's I suppose because the audio part
was running in realtime thread and decided itself when to yield cpu.
Hmmm ...
# man nice
NAME
nice - run a program with modified scheduling priority
SYNOPSIS
nice [OPTION] [COMMAND [ARG]...]
DESCRIPTION
Run COMMAND with an adjusted scheduling priority.
With no COMMAND, print the current scheduling priority.
ADJUST is 10 by default. Range goes from -20 (highest
priority) to 19 (lowest).
...
...
So if you do:
# nice -10 audioapp [audioapp-options]
.. your audioapp should repaint itself before any less urgent process
(with normal or slightly high priority) gets a chance at the CPU. JACK
will still run at (near?) highest priority, so if your audio-processing
demands 90% CPU there will be not so much repainting going on ...
is the only way to ensure the effects don't lag from control input to
make sure I run as little processes as possible and hope the input
thread will be scheduled often enough?
Nah .. You should be able to get your audioapps running at a priority
high enough to only be disturbed by themselves.
mvh // Jens M Andreasen