Description

It's interesting that the process of optimizing performance of a machine is called tuning. It holds true for automobiles as much as it does for computers designed for audio composition work.

Regardless, I've been conducting some more tests under Linux to see if I can get stable and reliable performance for a long time frame loop-network system. I was having troubles with the kernel and Jack, the audio routing software, which was leading to audio drop-outs. From here on in it just gets more technical, so if that doesn't interest you then I bid you farewell.  Just take this important message. Without the persistent networks of practice enabled by the internet, I could not in any way have made these refinements, and would remain at a loss as to how to tackle the problems I was having.

Anyway, I found this [1] page and followed the directions and found significant improvements in stability.  As a precaution, I have quoted the important part's below, in case the page goes offline or disappears.

Audio setup

We can (albeit oversimplifying) say that the higher the priority of a task the more likely it is to run undisturbed. With -rt kernels we have the option of making IRQ handlers run with a lower priority than certain user space applications. It is, for example, possible to run jackd with a priority greater then all IRQ’s which might disturb audio operation (like disk or network). We need the jackd -P switch for that.

In a default -rt kernel all IRQ handler threads have default priorities in the range of 40-60, so making jackd run with a priority of 70 is a good choice here:

jackd -R -P 70 -d alsa ...

But we also want the soundcard IRQ handler run at a higher prio than jack, as the soundcard irq is what ultimately drives jackd. Thus we can use the chrt utility to change this (my soundcard is on IRQ 4 in my system - make sure you check in /proc/interrupts what’s yours):

chrt -f -p 82 `pidof "IRQ 4"`

A priority of 82 is well above jackd. jackd also runs threads besides its main loop. Namely a watchdog at priority 10 above its main loop (80 in this example), and all clients’ process() threads will run with a priority 1 smaller than the main loop (69). 

I also made the following change for supposedly improving midi timing, but I don't use a lot of midi so haven't tested.

RTC,

The realtime clock every pc compatible has. This timer runs at a programmable frequency (i.e. 1024 hz) and thus enables the application to get run very often very regularly. To get RTC based timing to work nicely the rtc IRQ handler (which is # 8 on an XT-PIC system. Check /proc/interrupts to find out its IRQ) needs to get a priority above jackd and all the rest, so 98 is a good choice:

chrt -f -p 98 `pidof "IRQ 8"`

Finally, I wanted these to be automatically reinstated during boot, so I followed the following instructions as posted to the linux audio users mailing list.

On my FC5 system, I put this in /etc/rc.local :

/usr/bin/chrt -f -p <desired priority> `pidof "IRQ <desired IRQ>"`

Note: those are "back-ticks" encasing the "pidof" command, not single

quotes.

Thus, your command should be something like :

/usr/bin/chrt -f -p 90 `pidof "IRQ 10"`

The end result is I have been running a test configuration (20 variable live input loops of up to 5 minutes in length at 5ms round-trip latency) for over an hour without a single audio drop-out.  I'll leave it running overnight to see if the stability remains, but so far so good.