insanely long xruns with ardour-4.6

I use ardour since version 2 and I have my lowlatency kernel, jack and security limits configured for 2+ years. I started to experience xruns with 4.4 (and continued into 4.6) with insanely long durations. Sometimes the playback of recorded material stops momentarily, but sometimes for 20 seconds! the same happens during recording too. I never had xruns when I configure ardour session with busses and no tracks for live effects.

I tried to analyse what my system was doing then by bringing up the top with threads view and iotop. The session contains 2 mono tracks recorded at 48000kHz/float 32bit and 1 stereo track at 48000kHz/24bit.

When ardour works ok, top displays ardour and jack threads with prio -6 and -11 respectively consuming approx 10% of my CPU (Haswell Core i7-4700MQ 4 cores).
When ardour xruns(i have several seconds to check the situation), the high prio threads fall to the bottom of the list due to block (top output is sorted by consumed cpu). Immediately before the playback resumes, I can see a surge in io activity of ardour (read of several tens MB) in iotop. In between before xrun starts and playback continues, the system is pretty idle w/o much cpu and/or io activity.

I wonder what keeps ardour from doing io earlier? I have a laptop with 2 TB hdd coupled with 128MB SSD used as a cache (bcache backed volume). The HDD is capable of 100MB/sec read in best case. It seems to me that a normal prio thread in ardour that is responsible for io, is late to start read/write operations.

My system is Lenovo T540p Intel haswell i7-4700MQ, 16 GB RAM, 2TB hdd, 128MB SSD, intel HD 4600, NVIDIA Geforce 730M
I use RME Babyface at 48000Khz, 64 periods,2 buffers.

Thanks for trying to analyse this, but unfortunately, you’re not really looking at the right thing. Thread priority has a completely different “namespace” for SCHED_FIFO threads (used for realtime audio processing) than for SCHED_OTHER (normal threads used for just about everything else).

So lets start again by (a) noting that it is MUCH easier to talk about this sort of thing on IRC where we can interact in real time (b) asking if Ardour 2 is still functioning as you expect on this system

I have problems building ardour 2 on my system. I’m running gentoo so there are no binaries and the libs get updated fast. I’ll check with my distro support.

Ardour 2? We just released Ardour 4.6 … We don’t support self-builds, not out of spite, but because we don’t have the resources to help people with the many things that can go wrong. You can get Ardour pre-built from

rugubara: Sounds like a hardware problem to me, Either a problem with the hard disk or the audio interface. New disks might misbehave too. You might have a bad unit or there might be a problem with the disk firmware. This has happend to me.

I would start debugging by writing large files to the hard disk and monitoring its behaviour. If there are notable stops in writing then the problem lies in the disk. Next I would make long recordings with another audio software like Audacity with Jack and then ALSA alone and see if the problem appears there too.

When you record in Ardour and the problem occurs take a note what the hard disk led does. Does it stay on all the time or is it off. This might give you some clues of what is happening.