Jens M Andreasen <[EMAIL PROTECTED]> 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/
