18 Jun
2009
18 Jun
'09
5:12 p.m.
On Thu, 18.06.09 14:49, Paul Davis (paul(a)linuxaudiosystems.com) wrote:
In PA's ALSA module we use snd_pcm_avail() for this: only if it is
below a certain threshold we process those private events. If it is
not, then we go back to IO directly, assuming that it is too risky
trying to dispatch another event.
On Jack we have jack_frames_since_cycle_start(), would it be
considered an ugly hack if I use that to implement a similar logic?
for (;;) {
n = jack_client_wait()
process(n);
jack_cycle_signal();
while (jack_frames_since_cycle_start() < threshold)
process_one_of_my_private_event();
}
Just ugly? Or *too* ugly? Is jack_frames_since_cycle_start() costly?
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
So, to map
this to JACK, I would prefer if jack_cycle_wait() would
also exist in a non-blocking variant. i.e. something that can return 0
if there's nothing to process, but doesn't necessarily wait.
that's not possible. the thread has to be ready to respond to the
start of the JACK process cycle with RT-friendly timing.
thats why "do_my_other_work_if_there_is_any()" is still under RT
constraints *AND* needs to be designed knowing that
it may be stealing processor time from other parts of the process
cycle.