Florian Schmidt <mista.tapas@xxxxxxx> 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
