Florian Schmidt <mista.tapas(a)gmx.net> writes:
forgot an important one:
- decouple the partitioned convolution chunk size from the jack buffer
size. This will allow to run a 2048 frames chunk sized partitioned
convolution in a i.e. 256 frames jack graph. Of course the latency of
the chunksize remains, but i will set the jack port latency, so DAW's
like ardour can compensate for it.
There's code in JAMin to do this. It's a bit of a hack, but look at
the DSP thread logic in `src/io.c'. If the JACK buffersize is at
least 256 frames (our preferred FFT window size), io_process() calls
process_signal() directly in the JACK thread. Otherwise it queues the
data to a separate lower-priority DSP thread which calls it there. It
updates the port latencies accordingly and even handles bufsize
changes.
One simple improvement I'd recommend. JAMin runs its DSP thread at a
RT priority one less than the JACK process thread. It would be better
to add (log2(bufsize)-log2(chunksize)) to the JACK priority (only when
negative). Then, multiple JACK client helper threads could share RT
scheduling cooperatively, so the ones with lower scheduling deadlines
get to run first. I think that works for any collection of sizes,
assuming the total CPU bandwidth is sufficient.
So, assuming I make a compatible change in JAMin, with a JACK bufsize
of 64 frames we'd get...
JAMin DSP thread priority (7) = (9+log2(64)-log2(256))
jack_convolve thread priority (4) = (9+log2(64)-log2(2048))
Maybe we should invent a new JACK thread service to encapsulate this
concept for clients with cooperating realtime helper threads. I've
thought about doing that before, but there wasn't much point with
JAMin the only user.
Btw: All help appreciated. So if anyone wants to join
in, feel free
I can answer questions about the JAMin implementation. But, I don't
have time to actively help you right now. Maybe later.
Nice project, good luck!
--
joq