Problem with Ardour: keeps disconnecting from Jack

Installation & Configuration Linux
#1

Hi.

I’ve been setting up my Linux audio workstation on a Thinkpad with a PIII600 Mhz (might not be fast, but does the job). I have Jack working fine with as low as 2.7 ms with an USB soundcard without xruns in normal conditions. I can run Rosegarden and QSynth with a fairly big soundfont with no xruns and acceptable cpu usage, while I play with some drum tracks in Hydrogen, for example. That’s just to show that my setup is working fine, and that realtime privileges are correctly configured.

Now to the problem:
I can’t use Ardour. It keeps disconnecting from Jack, on about every imaginable occasion (like loading new music, hitting play, record or whatever), saying always: Ardour was disconnected from Jack because Ardour was not fast enough. In the console I see the message: Jack: client zombified. If I then do a “ls” I see that there is no Ardour process running with realtime privileges anymore. I then press “reconnect to jack”, it does it (ls really shows one process with realtime priority), but then anything I do will be enough to make it disconnect again :frowning:

What I am trying to run is Ardour2-beta12, freshly compiled (with no issues) on that laptop. I have Zenwalk Linux 4.0, with quite a few things actualized by hand.
I did have Ardour2 beta 11.1 before, had the same problem, so I hoped it could have been solved already, erased the whole installation, and went for beta12, only to have the same happening…
I don’t know what could be the problem: Ardour gets started with realtime priorities, but then just doesn’t keep up with Jack… something MUST be wrong, but I need help to find out WHAT it is…

Ah, and before installing Ardour 2, I gave a try to Ardour 0.99.3, it worked (didn’t disconnect from jack), but then, it had other bugs and was more limited, so I’d rather NOT have to go back to it… I see no reason why Ardour 2 shouldn’t work just fine on my system, if I got everything else working so great…
For the little I have been able to test Ardour out, I have already gotten the impression that it is really a great program, so its kind of sad I can’t use it yet… :frowning:
So, please, if anyone here has any clue on how to help me to get it running, I’ll be much happier (and promise to make a donation).

#2

I am seeing exactly the same thing, and I have been on just about every version of Ardour2 I have tried.

#3

Hi.
Thanks for the reply.
I did what you suggested (buffer size to 1024), and yes, it did stop the disconnecting thing. Works fine like that. But sure, unusable for me (need low latency). Ardour is compiled with sse support, at least it says so on start. Jack doesn’t seem to have it, at least doesn’t say anything. Will recompile it when I have time. But I don’t expect large improvements from that if already now it works fine with other apps to such low latencies without problems.

But now, there are a few things here I don’t get: why does Ardour have such difficulties in achieving good performance and good latency, while all other jack connected applications I have been using, even in their most weird combinations (cpu usage going up to 100% or whatever), in the worst case I get one xrun or another, in the best, only the windows get sluggish but everything works fine, so why does ardour DISCONNECT itself from jack, instead of just letting out a few xruns and then it’s ok? And that in the simple event of starting playback or record… With some latencies it doesn’t even start right: it’s enough to open a project or add a track… There must be something wrong here…

Also, I just discovered that there is a problem with jack latencies being displayed in Ardour… they are different from what I see in qjackctl (f.ex. 512 frames and 2 periods it shows 10.7, while qjactkctl shows 23.2…). Or is it a problem with qjackctl? I don’t know, but that there is something wrong, that’s for sure. Also, I can change them in ardour while jack is running, except for the 256 one! It doesn’t do anythingh, only the 128 then changes it… that’s weird… because in when set up with jack, 256 does work…
Now, don’t tell me to use -n3 , because my USB Soundcard doesn’t like that (yes, I am using one, and I did say that already in the first post, but it is working fine I can assure you, just do a quick reread on my first post and you’ll see why).

Regarding realtime priveleges and kernel, I have them all set correctly with set_rlimits (as zenwalk is based on slackware they don’t have pam), for example ardour is at 80 and nice -10 and 180MB memlock, that should be plenty enough…
In “ls” it does show up with priority -21, so that’s allright… jack is fine aswell, like I said before, I think I got it at 85…
Kernel is 2.6.20 patched with Ingo Molnar’s patches, IRQ’s are softhreaded (I just tried also to give the USB irq a 93 priority with chrt, which I don’t use to do, but it didn’t make any difference).
Now, I just tried starting ardour with jack set to 256 (which is about 10.7 ms here), and ardour did disconnect. I then reconnected it to jack, and nothing was working anymore: it didn’t disconnect, but there was NO audio output or input in ardour, even after checking all connections (they were fine), and cpu usage went constant to 100%, the same was being shown by ardour for the buffers. I couldn’t get it to do anything. That must be a nasty bug, no?

Well and that’s all I know or could try at the moment… I hope you or anyone else here will have some good idea to help me to solve it… I am sorry if I seem a little annoyed or a little too critical, but you must understand, I have been trying very hard to get ardour to work, I am no novice with linux nor audio realtime (have been setting up everything about this system and have everything working fine, except for ardour), and I can have this machine giving me good performance for quite a few surprisingly difficult things, and this at 5.8 or even 2.7ms… while ardour doesn’t even start correctly with 10ms, and you ask me to go to 1024, and ask about my realtime privs when I’ve just told you in my first post what I can do with my system… anyway, I think ardour is a great software (if not the best for linux out there), and I know it’s a beta, but what I think is that priority should go into making it easier and reliable to set up, before everything else… because, what people in real world audio production want first, is a stable, reliable recording program with low latency… all other great stuff figures second place…
sorry for the testament lol…

#4

Ardour’s tuning team has largely been targeting P4 and later processors. There is a great deal of SSE code in ardour now that may be pessimal for the P3, which had an SSE implementation best described as “lame”.

  1. The behavior you describe with jack and changing buffers around sounds like an old jack… do please update your jack to 103, compile with --dynsimd and make sure the jack fifos are on a tmpfs filesystem.

  2. you didn’t say if you’d compiled ardour with DEBUG=0

  3. if you are interested in trying the heavily optimized, extremely oprofiled, branch of ardour I’ve been working on, you can check out the “surfaces” branch.

svn co http://svn.ardour.org/ardour2/branches/surfaces

There some mildly broken code in there right now, but nothing to stop a test. (lots of warnings, tho)

scons DEBUG=0 TRANZPORT=0 FFT_ANALYSIS=0

Assuming you still can’t get low latency, an oprofile of the optimized code might reveal something at your “reliable” 1024 sample level…

#5

Comments inline:

I did what you suggested (buffer size to 1024), and yes, it did stop the >disconnecting thing. Works fine like that. But sure, unusable for me (need low >latency).

I note that, I use low latency for recording midi and designing drum tracks, but when I switch to playing back and recording the more complicated stuff I use ardour to “render” the results, thus obviating the need to run low latency - I generally move my samples/period up to 1024 so I get zero xruns. As one example I’m currently working on - a 12 track rosegarden midi file talking to 4 stereo midi devices, + linuxsampler with a 2.2GB sample and a 600MB sample + ardour2 - at 96khz, recording those 12 tracks is impossible at 2.6ms, glitchy at 5, and perfect at 10ms. (and it requires a 3GB RAM dual 1.6ghz opteron to do all this)

Which reminds me. Are you swapping at all? Swapping - at all - is bad.

Ardour is compiled with sse support, at least it says so on start. Jack doesn’t >seem to have it, at least doesn’t say anything. Will recompile it when I have >time. But I don’t expect large improvements from that if already now it works >fine with other apps to such low latencies without problems.

The other apps you mention are considerably lighter weight than ardour. Hydrogen basically operates off of cached samples, and rosegarden uses midi which involves hardly any disk I/O at all.

A fairer comparison would be to try doing audio recording in rosegarden.

But now, there are a few things here I don’t get: why does Ardour have such >difficulties in achieving good performance and good latency, while all other jack >connected applications I have been using, even in their most weird combinations >(cpu usage going up to 100% or whatever), in the worst case I get one xrun or >another, in the best, only the windows get sluggish but everything works fine, so >why does ardour DISCONNECT itself from jack, instead of just letting out a few >xruns and then it’s ok? And that in the simple event of starting playback or >record…

Starting playback or record are not simple events. In fact, they are just about the highest cpu using events there is (after startup, automation, or playing faster than 1.0 speed). A ton of files need to be created or read. Memory needs to be cleaned up and prepped. Etc.

With some latencies it doesn’t even start right: it’s enough to open a >project >or add a track… There must be something wrong here…

You are running with at least 1/3 the cpu any of the devs are.

Also, I just discovered that there is a problem with jack latencies being >displayed in Ardour… they are different from what I see in qjackctl (f.ex. 512 >frames and 2 periods it shows 10.7, while qjactkctl shows 23.2…). Or is it a >problem with qjackctl? I don’t know, but that there is something wrong, that’s >for sure. Also, I can change them in ardour while jack is running, except for the >256 one! It doesn’t do anythingh, only the 128 then changes it… that’s weird… >because in when set up with jack, 256 does work…

There is a new version of qjackctl out that I’m told does the right thing.

Now, don’t tell me to use -n3 , because my USB Soundcard doesn’t like that (yes, >I am using one, and I did say that already in the first post, but it is working >fine I can assure you, just do a quick reread on my first post and you’ll see >why).

I didn’t say nothin. We’re mostly RME-audio fanboys here.

Regarding realtime priveleges and kernel, I have them all set correctly with >set_rlimits (as zenwalk is based on slackware they don’t have pam), for example >ardour is at 80 and nice -10 and 180MB memlock, that should be plenty enough…
In “ls” it does show up with priority -21, so that’s allright… jack is fine >aswell, like I said before, I think I got it at 85…

I note that I memlock over 600MB.

Kernel is 2.6.20 patched with Ingo Molnar’s patches, IRQ’s are softhreaded (I >just tried also to give the USB irq a 93 priority with chrt, which I don’t use to >do, but it didn’t make any difference).
Now, I just tried starting ardour with jack set to 256 (which is about 10.7 ms >here), and ardour did disconnect. I then reconnected it to jack, and nothing was >working anymore: it didn’t disconnect, but there was NO audio output or input in >ardour, even after checking all connections (they were fine), and cpu usage went >constant to 100%, the same was being shown by ardour for the buffers. I couldn’t >get it to do anything. That must be a nasty bug, no?

Well… it may be. There may well be some interaction of ardour with a P3 that we don’t know of yet. You can help by oprofiling a bit…

#6

Get it reliable first, then, fast.

Increase your samples/period in jack to 1024 (for the sake of argument) also -n 3.
Fire up ardour2.

If ardour disconnects at that point:

  1. Is jack using sse (it should print that it’s using sse on start). Is ardour using sse? (it should print that it’s using sse). If either isn’t, then that explains a lot.

  2. did you compile ardour2 for debugging or optimized? A 600 Mhz P3 probably needs all the help from optimized code it can get. (scons DEBUG=0)

If you are using SSE and you compiled with full optimization and you can’t run at 1024 samples/period it is possible there is something deep wrong with the system and I’d suggest you’d hop into the irc channel for some in depth debugging.

  1. What are the realtime privs on your system? Are you using a USB device? is that device got realtime on it’s IRQs?

  2. Exactly what kernel are you running?

If ardour doesn’t disconnect with your period size set so high, well, many of the same questions above apply towards tuning it towards lower period sizes.

#7

Now, that’s what I’d call a MAJOR surprise!!
I got Ardour working PERFECTLY! It doesn’t disconnect anymore, not even at 5.33ms (in qjackctl… Ardour says 2.7ms). I can record well, just tested a recording from the output of qsynth while playing something in rosegarden (all this together is pretty heavy for a PIII600), and it didn’t complain at all, even the windows didn’t get too sluggish. I only got one xrun at the end.
So, now you and everyone reading this is going to ask:

What the heck did you do???

Well, first of all, I upgraded the kernel to 2.6.21-rc5-rt11. Because I wanted to get rid of some small problems I had with the 2.6.20 version, and after talking to Ingo he recommended me the new version. So, that solved a few minor issues in the system. I didn’t notice any improve in realtime audio, though, it was as good as before. Unfortunately I did NOT test ardour at that stage.
Then, I upgraded Jack to 0.103 and compiled it with all possible optimizations (SSE included). And then I tested Ardour, and everything was fine!
So, I think we both were right afterall:
I was right in that what Ardour is doing is not that hugely resource intensive so it could not run well with low latency on a 600Mhz PIII, if other applications can run there flawlessly doing also pretty heavy stuff (just for fun: I did a recording in rosegarden, did it fine), and you were right (thanks a LOT for telling me this!) in that Ardour NEEDS the SSE compiled in Jack… because I just can’t imagine that the kernel upgrade had anything to do with this… but well, we won’t know now, as I don’t have the time nor the will to break the system deliberately by going back just to test this, no, I am not crazy :smiley:
Anyways, I am pretty sure it wasn’t the kernel, I mean, I didn’t notice a difference in the system’s performance with other apps… so I think the single thing that made Ardour work well was recompile jack with SSE… I NEVER thought it had that much of an impact :open_mouth:
I think it would be a good idea for Ardour developers to put somewhere in the documentation a notice that SSE is absolutely needed for good performance…

So, finally this is solved… thanks again for trying to help me. I am sure I will be a very happy ardour user from now on (gotta make the first REAL recordings in the next days), and you can count on me making a donation in the near future.

#8

I’m very glad you got it working!

I note that we did get some reports of some issues with earlier 2.6.21rcx-rtX candidates, it’s good to hear the latest and greatest is working well.

What SSE can do for a system can be very impressive. Recently sampo improved the speed of a core routine in ardour by a factor of 26 with some hand crafted sse code.
We just cut total cpu usage in half (actually, for larger period sizes, by 2/3s) for the multi-panner I/O routines by switching to SSE.

Oprofiling ardour these days often shows that the SSE code still dominates the runtime, but in most cases, these routines are running below the noise floor.

I would be very interested in an oprofile of your system in “normal” ardour use.

And donations are always welcomed especially as the ardour team heads to the finish line for the ardour 2.0 release.

#9

Sorry to hijack this thread, but my problems are more or less the same. I tried to compile jack with sse, but the messages at startup still don’t say anything about sse.
Here’s my setup:
jackd 0.103.0, compiled with the following flags:

–enable-optimization-by-compiler
–enable-mmx
–enable-timestamps
–enable-posix-shm

To which I have added

–enable-sse

During compilation, there is indeed a check for sse, and a positive answer to it.
Well, if sse is the holy grail, I want to get it right…

Ardour: 2.0 (ardour2 -v says: Ardour/GTK 2.0
(built using 1762 and GCC version 4.1.2))

On a different subject, I also wonder about the startup message:

WARNING: Your system has a limit for maximum amount of locked memory!
This might cause Ardour to run out of memory before your system runs out of memory. You can view the memory limit with ‘ulimit -l’, and it is normally controlled by /etc/security/limits.conf

My limits were originally:

@audio - rtprio 75
@audio - nice -10
@audio - memlock 250000

I’ve increased that to 85 and 350000, and it seems to have had a positive effect, but since I’m mostly shooting in the blind here, I wouldn’t mind some advise about what the best settings would be.

Soundcard: plain ol’ intel 82801db-ICH4, Laptop, nothing fancy, but it works well enough for home-recording.