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

On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<mzynq@email-addr-hidden> 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@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 04:15:02 2009