On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<mz...@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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
