Troubleshooting advice, narrowing down to JACK or Ardour or other JACK client

Installation & Configuration Linux
#1

Ok, I’m having a few odd issues with three separate boxes running Ardour versions 2.8.1 and 2.8.2. One box is a CentOS 5 box with the PlanetCCRMA repository, one box is a Fedora 11 box running the PlanetCCRMA repository, and the third box is running AVLinux 2.0r2.

All are having similar problems and instabilities related to exporting from Ardour to an output .wav file, and all are having some issues with Qjackctl refreshes of Ardour tracks that are added.

My issue is trying to determine where the fault lies; is it a JACK issue, or is it an Ardour export issue (or is it something else?). So I’m looking for advice and pointers to tools as to how to determine this.

The two PlanetCCRMA boxes are running the PlanetCCRMA -rt kernel and jack packages (which do all the mods to /etc/security/limits.conf required, installs the rtprio package, and other things), and the rtprio for JACK has been, pardon the pun, jacked up to 72. An export from Ardour works, but Ardour after the export won’t work anymore; JACK is throwing a ‘cannot create realtime thread’ error ONLY after the export is done (there are no such errors thrown when Ardour starts up, and many hours of use of Ardour up until an export is done throws no errors). I also get xruns during export (and ONLY during export) occasionally on these two boxes. These two are running Ardour 2.8.2. The JACK version on the F11 box is 1.9.2; the C5 box isn’t available right now for me to look at it.

On the AVLinux box, the symptoms are different, but just as disruptive. After an export, the connections in qjackctl go crazy; no new connections can be made, and connections done inside Ardour don’t ‘take’. After a half dozen back to back exports, I start getting ALSA xruns, and after keeping on a while, I get increasingly slow response times, and eventually a hard crash. The JACK version is the custom JACK that ships with AVLinux 2.0r2, which is based off 0.116 I think, and the Ardour version is 2.8.1.

If I exit Ardour, stop/start JACK, and then restart Ardour, things work ok again for as many hours as I work in Ardour editing, playing, recording, etc, until I export, at which time things break again. Disconnecting and reconnecting to JACK inside Ardour does not clear the issue; only a restart of JACK will solve the problem.

This is not the first issue I’ve had with Ardour’s export; an older (don’t recall off the top of my head which one) version consistently hangs after the export on a Fedora 8 box if (and only if) the export uses JAMin. I experienced a hang like that with AVLinux 2.0r2 a few days ago on Ardour 2.8.1, but it isn’t consistent.

I’d love to determine which package to file a bug report for, but I don’t want to file against the wrong package.

#2

Full error text:

Cannot set scheduling priority for RT thread res = 22 err = No such file or directory
Cannot start thread

But is only thrown after an export.

Verbose mode trace is/can be available.

#3

Ok, updated JACK on the F11 box to 1.9.3, and there’s no difference in the export behaviour.

#4

lowen,

For your info, AV Linux 2.0r2 came with JACK 0.116.2 from SVN built with custom ffado support that was then not yet available in the official Debian Repos, JACK 0.116.2 with ffado support is now available in the Debian Testing Repos, you could probably safely update and try it, It handles -rt permissions a little differently so if you install it say yes to it enabling -rt permissions. The next AV Linux release will use JACK2 and also includes the rtprios command line utility to play with -rt priorities.

Are you using the stock AV Linux kernel or the -rt optional one?

#5
stratojaune: And, maybe something to change in "-Phw:1" ?

That’s one of the ‘oddities’ of the jackd command line; -P’s meaning changes: after the -d it is seen to be the same as --playback, whereas if seen before the -d, it means --realtime-priority ; or are you referring to something I should put there other than that? My choices are pretty limited; this box’s internal HDA Intel card is not able to be disabled in the BIOS, so it has hw:0; the ICE1712 only shows up as hw:1 and hw:1,0 in the qjackctl setup (jack is being started by qjackctl). But I can’t see how the alsa parameters could impact how the Freewheel-using export mode interacts.

I’ve been having lots of fun with the F11 workstation; it’s a Dell Precision M65 laptop with a D/Dock. Inside the D/Dock, in the PCI slot, is the Delta 1010LT. Only one PCI slot in the D/Dock; this is important given the IRQ situation. The M65 has an nvidia Quadro FX 350M. With the proprietary nvidia drivers loaded, the nvidia card hits IRQ16; the Delta1010LT is there, too. Without the nvidia driver, no IRQ for the nvidia card (and no IRQ16 sharing, and no audio glitches). But scrolling in, say, Firefox, is so slow as to be painful without the nvidia driver (and the kernel DRM with noveau on the -rt kernel wasn’t working last I heard), and with the nvidia driver I get ALSA xruns occasionally, causing blips in the sound. BIOS setup doesn’t have any IRQ knobs to tweak, so I’m still looking at how to get APIC steering to work properly with the PlanetCCRMA rtPAE kernel. Yeah, I know a laptop with a Delta 1010LT seems like overkill, but it makes a killer portable outfit; I could pop my Delta 1010 (non-LT) in there and use that, but I’d have the same issue. And the M65’s Firewire chip isn’t the best in the world for audio devices, unfortunately.

But that’s not related to this issue.

Also, the occasional XRUNs during export seems to be related to the RT priority settings; higher is not always better, I’m finding. There is a sweet spot; for now, that sweet spot is a little lower than the 80 I put above (the 80 works fine if I’m not using the WiFi; if the WiFi is on, I get strings of many XRUNs, until I lowered RTPRIO for JACK to 78, at which point I quit getting XRUNs during export; note that I wasn’t getting any in non-export mode with either setting).

seablade: Not sure. I suspect a problem in Jack, but this is the first I have heard of that particular problem.

And you’ve hit the nail, here. How can I ‘clear’ Ardour and ‘blame’ jack (Jack 1.9.2)? Or vice-versa? If I just knew which file wasn’t found, it might help things a little. I do note that jack goes into non-RT mode during export, and then tries to go back to RT mode, which fails. I’m going to try with SELinux set to off (I’m not getting an SELinux AVC denial, so I don’t think that’s the issue, but it can’t hurt to try), and also see if I can grab the source RPM’s from PlanetCCRMA, update to Jack 1.9.3, and rebuild to see if that fixes the issue.

And one other odd (slightly off-topic for this thread) thing I’ve noticed is that only sometimes can I get the CPU % to be close to 100 during export; it used to be, back in earlier days (pre-Jack2 in PlanetCCRMA, that is), that it loaded the CPU fully during export, which made the export go much faster. But yesterday, after adjusting the RTPRIO down to 78 (from 80, which had worked before with the WiFi off), the best I could get was 40-45% CPU and even then the majority of the time the CPU was only at 23% or so. And the export (of a 28:00:00 WAV from a three-track source, with only one track piped through JAMin) took ten minutes. I think a lot of that had to do with JAMin, though. I’d love to find a command line way of piping an arbitrary WAV through JAMin (or any other JACK program) and record the result to another WAV, using the Freewheel driver like the Ardour export does.

#6
GMaq: JACK 0.116.2 with ffado support is now available in the Debian Testing Repos, you could probably safely update and try it, It handles -rt permissions a little differently so if you install it say yes to it enabling -rt permissions. The next AV Linux release will use JACK2 and also includes the rtprios command line utility to play with -rt priorities.

Ok, thanks for the information. I have found, however, that changing the install in virtually any way can break things; I installed a few KDE programs, and the fonts went weird, for instance. And I then started having odd issues with the US428; the first one or two times I attempt to start Jack with Qjackctl, the initialization of the alsa backend fails. Third try usually works fine. Probably related to some dependency those KDE programs brought in; I’ll probably wipe and reinstall from media and leave it alone, as a stock install worked pretty well, I’ll just have to remember that that laptop isn’t a ‘general purpose’ box any more.

Living with Debian Testing, is, pardon the pun, rather Testing at times. This is the second reinstall from media; updating to the Debian Testing jack a few weeks ago resulted in serious instabilities, which is what prompted the reinstall. That was before your post on that topic to the AVlinux forums; I had just been updating as updates came in, which is SOP for a Fedora box or even a Ubuntu box. Not a wise thing to do with Debian Testing if you want the box to be stable!

For the thread’s benefit: the AVLinux 2.0r2 box is a Dell Inspiron 640m, 2.0GHz Core 2 Duo with 2GB of RAM, and a Tascam US428 USB audio I/O and control surface. The US-428 has 4 inputs (2 are selectable mic/line with XLR and TRS 1/4’s, 2 are TRS 1/4’s with a mic/line/guitar switch and the ability to do S/PDIF), 2 outputs, 24-bit 48Ksps converters, MIDI I/O, an eight fader control surface with the normal transport controls among others, and great sounding mic preamps for all four channels. Cleaner, IMO, than the Delta 1010LT’s preamps, and cleaner than even the vintage Gates Radio Gatesway broadcast console tube preamps I have available to me.

GMaq: Are you using the stock AV Linux kernel or the -rt optional one?

Stock. So far it has been working well for the type of overdub recording I needed to do; max of two channels going in at any one time, with great hardware monitoring, and headphones for the overdubbing ‘mix-minus’. And since the time pressure has been on for this project, I was hesitant to ‘experiment’ too much with both of my portable outfits, since I had to have one available whenever the artist was ready to record each instrument and each vocal track (at a church with great room ambiance, so it had to be portable; the rackmount PC with the Delta 1010 and the racked Gatesway preamps is just too heavy to move around much). So I haven’t yet tried the -rt kernel on AVLinux, sorry.

I have, however, essentially been to Ardour bootcamp doing the project, and I fully intend to document techniques that I’ve found work really well in Ardour for single-artist multitrack overdubbing. As well as techniques that don’t work so well.

#7

lowen,

I agree…don’t get me started on living with (perhaps dying from) Debian Testing this week!

The -rt Kernel is a concession mostly because people think they need it, I much prefer that people use the stock Kernel. The only real difference is a pronounced improvement with M-Audio 1010LTs which are a hit and miss affair with JACK depending on what chipset revision they have. I’m happy to hear you are finding the stock kernel adequate.

Next AV Linux should be treated like Dynebolic… image based and to be left alone until further notice, hopefully it will be Stable and productive enough that people aren’t obsessed with updating for quite some time. It will also have GIT Buildpackage and bookmarked GIT Pro Audio Apps for people to build their own updates if they really want to. Despite Debian Testing’s extreme volatility of late they have a phenomenal re-energized multimedia GIT packaging team bring a lot of great Pro Linux Audio Apps into the Sid and Testing Repos, that is very exciting at least.

#8

Not sure. I suspect a problem in Jack, but this is the first I have heard of that particular problem.

 Seablade
#9

Not sure of this, don’t have same hard than you, but here have increased frames/period to 1024 to mix and export and it’s nice… And, maybe something to change in “-Phw:1” ?

Good luck !

#10

No, sorry. ALSA.

Jack command line (from the verbose trace):
12:59:16.636 /usr/bin/jackd -v -R -P80 -dalsa -r44100 -p256 -n2 -D -Chw:1 -Phw:1

Device info:
creating alsa driver … hw:1|hw:1|256|2|44100|0|0|nomon|swmeter|-|32bit
Jack: control device hw:1
Using ALSA driver ICE1712 running on M Audio Delta 1010LT at 0xdf20, irq 16
configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 2 periods

#11

What backend are you using? Is it FFADO by any chance?

 Seablade