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.