Subject: [linux-audio-dev] Re: jack, low latency and IO
From: Artem Baguinski (artm_AT_v2.nl)
Date: Tue Dec 07 2004 - 17:42:57 EET
Jens M Andreasen <jens.andreasen_AT_chello.se> writes:
> 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?
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.
> 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 ...
[...snip...]
> 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.
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/
This archive was generated by hypermail 2b28 : Tue Dec 07 2004 - 17:52:21 EET