[LAD] [Jack-Devel] jack2's dbus name

[Lennart Poettering]

On Thu, 18.06.09 14:49, Paul Davis (paul at linuxaudiosystems.com) wrote:

> > 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.

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