18 Jun
2009
18 Jun
'09
7:41 p.m.
On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<mzynq(a)0pointer.de> wrote:
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?
Its (a) ugly (b) illegal - frames_since_cycle_start() is legal only
within the process() cycle but your code is not bounded by it (c)
fundamentally incompatible with basic RT programming. You're in a
thread which is competing for cycles with other JACK client threads,
and up against the deadline of the next cycle.
I don't see any reason why you cannot do what every other app that is
fundamentally not interested in real time does: put all your normal
code behind a ringbuffer, and just have your jack process cycle
pull/push from/to the ringbuffer.
the closest example i've seen to what you seem to want to do is
something which does FFT on the incoming signal. FFT has a certain
window size, and its costly in cycles, so you either cause spikes in
the RT load periodically (every time there is enough data to process -
assuming you're not using a sliding window) or you push the FFT out to
another thread and make the RT thread simply notify the FFT thread
that there is more data available.