I am still producing a set of instructions on HOW I got this... but to summarize:
1) boot-time option a) "nosmp" b) (default) -> uni/smp toggling the kernel
2) jack driver a) jackd -d dummy b) jackd -d firewire -> jackd-dummy / ffado "setup"
under nosmp: dummy and ffado work fine
under smp: dummy works fine but ffado exhibits xruns and usually at one particular time.
The xruns occur regardless of jackd settings 3x128@48kHz or 3x512@48kHz (note dummy only works in 2x mode).
testing proceedure is to reboot and set boot time option (if needed); start terminate and swapoff -a then htop; then start qjackctl with settings for dummy or ffado and start it (note: my qjackctl also disabled cron and I have no "System" update service configured so no surprise scheduled system events hopefully). then I proceed to start jackd and ardour... from here I record 8 tracks at 8 channels (64) to produce a lot of disk I/O.
the xruns occur USUALLY at (or before) when all un-used memory (which is used for disk-caching) is filled and the disk caching goes into FIFO (first in first out) for re-use of caching newer disk I/O data.
The xruns are ALWAYS 2 right next to each other... and since there is three buffers and three notable jackd threads ... I suspect ONE thread is stuck busy (perhaps BKL w/ SMP) and the other two threads cannot stream as normal until that stuck thread is awaken on next pass...
it appears that ONCE the two xruns occur, it's stable past that point. I've spent a bit of time and I can run more test / enable options during compile / checkout svn changes...
dummy does not cause this issue in SMP or UNI ... I think this IS a threading issue and not sure if it's in the core streaming API / interface or down in the driver part. (hence ticket 180) .. I will close ticket 179 in place of this one as I think I've narrowed it down to something SMP/threaded related.