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

Paul Davis paul at linuxaudiosystems.com
Thu Jun 18 21:41:43 UTC 2009


On Thu, Jun 18, 2009 at 3:12 PM, Lennart Poettering<mzynq at 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.



More information about the Linux-audio-dev mailing list