> I have tried ardour and qarecord for recording without xruns. > I know there are some problems in ReZound from this point of > view (and Davy knows about them much better :-). I have hoped, > you know some magic steps to configure something somewhere > to eliminate the issue at current ReZound state :-) > > Well, may be it is offtopic for this thread, but another question > is here: which (and where is it) kernel patch is most appropriate for > jack-functioning for 2.4.26 (I have applied lck1 patch)? I will assume you're using a SCSI system, and/or have your IDE tuned to use -d1 -u1 -c1 -m16 appropriately, and have 80-pin cables to do full UDMA/100 (or better) performance. 7,200+ RPM drives are also a Good Thing(tm). One thing people forget in tuning their system, is configuring their VMM system to not postpone dirty buffer flushes to disk. Actually, if you CAN try to avoid using swap at all, or use a dedicated swap device on its own IDE channel (or use SCSI). Do not underestimate the logjams of contended I/O devices. Also, you'll want to keep a reign on dirty buffer highwater marks. System defaults are not tuned for deterministic latency, i.e., writes are delayed until there's a lot of them. To produce more even and distributed writes, you might want to try: Assuming an HZ=1000 kernel... echo "10 64 0 0 2000 15000 90 5 0" > /proc/sys/vm/bdflush Assuming stock HZ=100 kernel: echo "10 64 0 0 200 1500 90 5 0" > /proc/sys/vm/bdflush This means: wakeup bdflush() at 10% dirty buffer levels, issue 64 block writes maximum per pass, wake up every 2 seconds, don't let dirty buffers age more than 15 seconds. bdflush() can go into "panic mode" to use synchronous operations when dirty buffers reach 90%, and bdflush can stop waking up when dirty buffer levels get to 5%. Defaults provide for a more deferred bdflush interval, and much larger I/O requests [500 blocks], which can flood the device's request queue and block other writes from occurring. If you're using lck1, are you also performing a "echo 1 > /proc/sys/kernel/lowlatency" ? Try 'nice -10'ing your problematic process. Also, avoid using ext3 in its default mode, ordered writeback. Instead, mount it using writeback journalling mode. Large pending journal updates tank latency as a sizeable operation needs to be performed atomically. The mount options for ext3 (if you must use it) would be: -o journal=writeback,noatime /etc/fstab entry would be like: /dev/hdc1 /barad-dur ext3 noatime,journal=writeback Note: this mode still journals all meta-data writes, but data CONTENT is now write-ordered, so you might not have the data you expect in a kernel OOPS/crash scenario, but your filesystem structures won't be damaged. noatime turns off the potentially disruptive ACCESS time updates (needless write pollution if you're reading many files during the course of your sessions). Modification time updates are still performed of course. When the Lady Galadriel comes calling, be sure of your Quality, =MB= -- A focus on Quality.
