[PlanetCCRMA] updated: jack

[Fernando Pablo Lopez-Lezcano]

> I caught a few lines of discussion regarding the new way jack temp
> files are stored.  But I'm still not all too clear about it exactly... 
> The idea is that now a mount point will be created in memory rather
> than on disk?
> 
> Here's what mount tells me (whether jackd is running or not);
> 
> [root@ruined /]# mount
> /dev/hda2 on / type ext3 (rw,noatime)
> none on /proc type proc (rw)
> usbdevfs on /proc/bus/usb type usbdevfs (rw)
> /dev/hdb1 on /archives type ext2 (rw,noatime)
> /dev/hda1 on /boot type ext3 (rw,noatime)
> none on /dev/pts type devpts (rw,gid=5,mode=620)
> none on /dev/shm type tmpfs (rw)
> none on /var/lib/jack/tmp type tmpfs (rw)
> 
> The last entry seems new and is where jack temp files are created.  Is
> this correct?

That is correct, the mount point was added by the postinstall script of
the jack rpm. 

> Of what benefit is it to have these temp files store there?

It used to be that those files were created in /tmp. Amongst those files
are the pipes that are used to transfer execution between all the jack
clients and jack itself (one process writes to the pipe and awakens the
process that is waiting on a read at the other end of the same pipe).
Apparently when something is written to those pipes (which happens
everytime there is a context switch between jack and its clients or
between clients) the inode is schedulled to be written to disk and thus
touches the journal file (if you are running /tmp in an ext3 or reiserfs
filesystem). So you are actually forcing writes to disk all the time (or
so I understand). Of course if the disk is fast enough or you are not
doing anything that's disk bound things are fine. As soon as you start
fighting over disk access with other processes there can be a delay,
actually a big one! And that delay is in the middle of the whole
schedulling bottleneck of the jack round robbin chain of execution. Ie:
instant xrun. 

So the idea is to create a filesystem in RAM where those pipes and other
temporary files can live without ever touching the disk. 

In the case of my laptop the results were dramatic, from having big
xruns (sometimes, always related to disk activity) when running 2x1024
to reliable operation at 2x128...

-- Fernando