jackdmp vs jack...... is there a real benefit .. or should I go back to jack mainstream version

I noticed this from Paul in another post

    the data flow through JACK is rarely parallelisable.

I have been using jackdmp under the belief that I would get more usage out of my dual-core cpu. Going from what little I know of these things, I thought each individual track maybe run as a separate thread and if these tracks had many plugins this would be very useful.

I’m not great at understanding how these things work, but Pauls comment has me questioning whether this is really the case.

Can anyone shed some light on this?

JACK cannot help with parallelism inside a client. It can only help with external parallelism. Jackdmp currently helps in situations where you have, for example, 1 client (or just the backend) feeding 2 other clients. Without jackdmp, these 2 clients would be run one after the other; with jackdmp they will run in parallel. However, most people tend to run audio processing as a single chain.

I do plan to work on Ardour’s internal parallelism sometime early next year.

Stephane also has an experimental version of jackdmp that tries to achieve parallelism by “slicing” up the process callbacks. Suppose the period size is 256. Rather than tell every client to process 256 one after the other, you tell the first one in the chain to process 32. After that, the second one can process the output of the first (32 frames) while the first works on the next 32. After that, a third client could work on output of the second, and so on and so forth. Its a clever idea but it needs careful measurement to see whether or not the cost of effectively running with smaller periods (as seen by the clients) is less than the gains of being able to use multiple processors.

Thanks for the update… Sorry about the delay in response… work has gotten pretty busy (weekends too) … and I’m struggling on finishing my next release…

To my experience jackdmp allows 0 xruns at the end of the day whereas jackd reported 3 or 4 xruns on the same settings. Theses xruns occured mainly when launching big apps anyway and were not a real pbm under recording.

However the other benefit is to achieve a lower latency. With a Terratec EWS88MT (envy24) i was at p=256 and n=3 and now run with p=128 and n=2 (!).

I run 3 apps (Ardour/MusE and PureData) on a E6700 intel Core2 (2.66ghz) and i am very satsifyed with the low latency and the reliable setup.