It must be a config thing(I hope). I don’t recall this happening in the past, but lately upon startup Ardour indicates 32 ms of latency, whilst jack be configured for 256ms(I don’t have a superfast machine…or maybe I don’t know how to optimize my config). I’m assuming this causes the frequent disconnects? Anyone know?
err, wait a ms. What I mean is, when Jack’s set for 256 frames/period + 2 periods/buffer = 11.6 ms, is it correct for Ardour to indicate 32ms under the Jack/Latency dropdown menu? There’s also another time value indicated on the far right of the menu bar(where it shows DSP%, disk space etc.) of 5.8ms. Is this another measure of latency? These are dumb questions and I wish I could delete this thread, sorry.
There is no single definition of “latency”. What JACK and Ardour show you are not the same thing.
Ok, thank you for the reply. I would like to understand more about how Jack and Ardour interact, i.e, what causes them to disconnect and can it be improved via configuration options. Anyway, for the most part things run smoothly but there are some issues…
Hi Paul,
sorry but I confirm that ardour and jack frames/period mismatch at (and only at !) 256 (jackd … -p256); in that case, ardour (Jack->latency) displays 32 instead of 256 (either the two ones match).
I don’t know if it is indeed of consequence, I did not go inside ardour encoding; but it is just the set of parameters (-r88200 -p256 -n3) for which I begin to experience a strong instability with my Pro 40 - and the limit for human perceptible latency (around 8ms).
It is also true that this (instability - xruns) arises when requiring a lot of tracks/effects in ardour coupled with jamin (usually not when real time is required) but any increase in stability would be of interest to ensure live sessions/recording. So, I think it would be of interest to take a closer look to this.
Thanks for your many works.
Regards,
Phil
PS: invoved is 2.8.16
ardour3 already provides multi-processor DSP support. the issue you are seeing in JACK > Latency is a small GUI detail that I think may already be resolved in ardour3. the limits for latency are caused by your system, not by ardour (or put differently, the limits
caused by your system will be encountered in most cases before those caused by ardour).
Jamin is known to be a massive CPU hog, and not a particularly high quality processor. There have been several discussions about this both on the Linux Audio Users mailing list and maybe even here on the forums, and the consensus from smart people is that there are much better plugin solutions for what Jamin is used for. They use less DSP/CPU, don’t cause distortion and generally just do a better job. I regret that I personally cannot offer you any recommendations but if you search around, you’ll find some.
Oh, so it is just a GUI bug. As a ffado developer, I just try to track any potential source of desynchronization; ardour+jamin provides a lot of cpu load, interesting for testing what may come from cpu and what may imply the firewire driver (knowing that the firewire controller is also obviously involved). I just remarked the coincidence; I will have a try with ardour 3.
Concerning jamin, I hear that some people claimed that some plugins do a better work; well, let see; spectral decomposition of the audio signal will whatever imply Gibbs phenomenon, so I will be curious to see how it would be handled( except increasing the samplerate and using 64bits).
Regards,
Phil