[linux-audio-dev] jack, low latency and IO

Jens M Andreasen jens.andreasen at chello.se
Tue Dec 7 13:27:25 UTC 2004


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





More information about the Linux-audio-dev mailing list