[Ardour-Users] jack and ardour disconnecting/crashing while using Csound

[Fernando Lopez-Lezcano]

On Thu, 2008-10-23 at 15:22 +0200, Jörn Nettingsmeier wrote:
> Paul Davis wrote:
> > On Thu, 2008-10-23 at 02:16 -0400, Hector Centeno wrote:
> >> Hello,
> >>
> >> I just worked on a project that involved recording several tracks of
> >> sound synthesized by Csound in realtime (tried both official 5.09 and
> >> CVS build) plus ambisonic ladspa panners, ambdec (ambisonic decoder)
> >> and jconv (convolution application). I started this project using
> >> Ubuntu Studio Linux and ended it with OpenSuse (both using their
> >> respective RT kernels and getting same problems with both). It became
> >> a very unstable combination since every time I stopped Csound,
> >> randomly Ardour would disconnect from jack or jack would crash, and
> >> then I was unable to make Ardour reconnect after restarting jack (it
> >> would complain about not being able to reconnect the ports). It was
> >> happening so regularly that I had ready on my desktop a couple of
> >> scripts to restart everything.
> >>
> >> Is there anything I could do to avoid this? Is it Csounds fault? Is it
> >> my system? Jack is running like this: jackd -R -P60 -p1024 -t2000 -u
> >> -dfreebob -r48000 -p1024 -n3 -D (using a Edirol FA-101). Could this be
> >> a realtime priorities issue? I installed the rtirq script by Rui Nuno
> >> Capela tunned to prioritize the firewire ports and made sure Jack is
> >> running at a lower priority (firewire is at 70). Jack's version is
> >> 0.109.2 and Ardour's is 2.5.
> > 
> > Some of your instability probably comes from JACK 0.109.2 (not all of
> > it, but some). There will be a new release out very soon which will fix
> > the JACK-contributed portion. If you feel comfortable doing it, then you
> > can use JACK from svn already.
> 
> i second that. 0.109 has been really flaky for me, and svn improved
> stuff *a lot*. 

And jack 1.90 has been even better (I have not tested very recent plain
jack svn). I have switched to jackmp at CCRMA and we are happy so far
(only issue I know off is you need to run jackmp with "-S" if you are
using crappy hda-intel hardware...). 

> my ffado setup is still not as rock-solid as my rme
> digi9652, but usable.
> 
> > I repeat what I have said so often: there is almost never any reason for
> > users to use the -P flag to JACK. Unless you are working on a special
> > system, just leave JACK to pick priorities. 
> 
> hmmm. qjackctl will always set it iirc, which is why everybody ends up
> using it. maybe we should approach rui to change that behaviour?

I think qjackctl does not change the default unless you tell it
specifically to do so (what qjackctl should _not_ have is the option to
change the number of channels! - AFAIK it has never failed to create
problems when "tweaked", and never solved one :-). 

Strictly speaking Jack does not "pick priorities". It just uses whatever
was compiled in the binary. Statically. Whether that choice is optimal
in a given box depends on what the distribution packagers did. If you
add something like rtirq to the mix (and it was not accounted for in the
original tweaking) you most probably will have to "tune" the priorities
of jack. 

-- Fernando