New Package for Review: jack-audio-connection-kit

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Thu Mar 24 22:48:33 UTC 2005


On Thu, 2005-03-24 at 14:30, Ignacio Vazquez-Abrams wrote:
> On Thu, 2005-03-24 at 14:02 -0800, Fernando Lopez-Lezcano wrote:
> > On Thu, 2005-03-24 at 12:29, Ralf Ertzinger wrote:
> > > Hi.
> > > 
> > > Aaron VanDevender <sig at netdot.net> wrote:
> > > 
> > > > This package requires a tmpfs to store some FIFOs and sockets.
> > > 
> > > Why can't it stick those in /tmp, for example?
> > 
> > Because there are problems with journalled filesystems (ie: ext3). The
> > disk activity interferes with the named pipes that Jack uses for
> > interprocess communication and creates latency hits. 
> 
> I always thought that FIFOs and sockets only actually existed in Linux's
> VFS, and the on-disk inodes were only needed to identify them in order
> to connect. Have I been mistaken all this time?

I really don't know, but the effect is drastic on Jack's operation. With
the pipes/fifos in /tmp you get drastic latency hits. See the appended
email for the first email (by Jeese Chappel) about this. 

-- Fernando

-----Forwarded Message-----

From: Jesse Chappell
To: jackit-devel
Subject: [Jackit-devel] xrun holy grail!! (for at least some)
Date: 05 May 2003 22:48:38 -0400

For those of us who have seen periodic and terrible overruns 
associated with disk activity, I have found the culprit!

By default, jack uses /tmp for its FIFOs and unix sockets.  For 
people (like myself) where /tmp is on a reiserfs filesystem, 
periodic writes were occurring by the filesystem to flush file 
access modifications constantly occurring when the jack fifos 
were are use.  Under light disk loads these did not cause 
overruns, but under medium to heavy disk loads, I believe those 
fs flushes were being starved, thus causing potentially massive 
overruns to JACK.  Whether this can be fixed in the kernel, I 
don't know, but it does happen.

By mounting a ramfs filesystem and telling jackd to put its 
temporary files there, and using a client that supports it, all 
such overruns I was having disappeared!
I know this will solve the problem for people with reiserfs, it 
might also help others.


# mkdir /mnt/ramfs;
# mount -t ramfs ramfs /mnt/ramfs
(set permissions appropriately if running as user)
# chmod 777 /mnt/ramfs

# jackd --tmpdir=/mnt/ramfs -R -d alsa -d hw:0 ......
(or jackstart)

start a client that supports setting the jack tmpdir
# jack-rack --tmpdir /mnt/ramfs ......

Hammer away at your disk and watch the jackd output.
I used command like this to hammer:
  dd if=/dev/zero of=blah bs=1000 count=1000000

Without the tmpdir on a ramfs, I would get 2-5 *second* xruns 
with that kind of hammering (at any buffersize).  Now I can get 
perfect performance with a intel8x0 with -b 128 on a thinkpad 
A31!   Bring on the HDSP....

jlc





More information about the fedora-extras-list mailing list