7 Dec
2004
7 Dec
'04
11:41 a.m.
Jens M Andreasen <jens.andreasen(a)chello.se> writes:
[...snip...]
yep. thanks for the enlightenment.
--
Artem Baguinski: http://www.artm.org/
V2_Lab: http://lab.v2.nl/
V2_ Organisation for the Unstable Media: http://www.v2.nl/
On tis, 2004-12-07 at 13:07 +0100, Artem Baguinski
wrote:
well, i meant an abstract input device ;-) not necesserily MIDI. may be
some thing i'll solder and connect to a parport of a serial port or
firewire or bluetooth. something i'm gonna want to use to control
[say] my soft synths.
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.
so i suppose this will be still valid for any other input... i see.
Suppose I have several various devices that control various aspects of
sound generation / processing. they all send "handful of bytes" now
and then and I want my JACK client to react immediately. Does it make
sence to have one high priority "input thread" to handle all of them?
Shall I request real time scheduling for this thread(s)?
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.
I was talking about delay between the acttion of the user [mouse
button click in this case] and reaction of the sound generation /
processing stuff. I don't really care if button gets redrawn half a
second later if the effect starts right after i click. But I suppose
I'd think twice what sort of GUI controls and feedback to use
now. thanks again.
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 ... 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 ...
right.
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.