Robert Jonsson wrote: >Hi, > >onsdagen den 21 januari 2004 23.05 skrev Glenn McCord: > > >>Andrew Morton wrote: >> >> >>>Could someone give me a really simple description of how to obtain Jack, >>>and how to get it going sufficiently to demonstrate these problems? >>> >>>Thanks. >>> >>> >>Go to |/usr/src/linux/include/linux| (or wherever you have your kernel >>sources) and in the file |capability.h| change the line >> >>#define CAP_INIT_EFF_SET to_cap_t(~0&~CAP_TO_MASK(CAP_SETPCAP) >>to >>#define CAP_INIT_EFF_SET to_cap_t( ~0 ) >>and the line >>#define CAP_INIT_INH_SET to_cap_t(0) >>to >>#define CAP_INIT_INH_SET to_cap_t( ~0 ) >> >>Also make sure CONFIG_TMPFS is turned on. >> >>You must then recompile your kernel. >> >>put this in /etc/fstab (you may have to ceate the folders) >>shmfs /dev/shm shm defaults 0 0| >>none /tmp/jack tmpfs defaults 0 0 >> >>||none /mnt/ramfs tmpfs defaults 0 0| >> >>Get jack at http://jackit.sourceforge.net/ >>do a ./configure --with-default-tmpdir=/mnt/ramfs --enable-capabilities >>make >>make install >> >> > >I believe that the kernel change can be omitted if you run the app as root. >The --enable-capabilities can also be omitted in that case. > >The tmpfs usage could call for some explanation: >jack uses the filesystem to store ipc pipes. It was discovered that accessing >these was the cause of xruns under kernel 2.4. >Thus it has been common to place these pipes on a tmpfs filesystem whereas the >xrun problem would not appear. I commonly have all of /tmp as tmpfs (then >jack doesn't need any special compilation flags). >I imagine this is a quite uncommon usage of tmpfs, maybe that's where the >problem lies with 2.6? > > > > >>http://jackit.sourceforge.net/docs/faq.php is a good explanation of >>everything anyway.. >> >>I start jack as a user with >>$jackstart -R -v -d alsa -d hw:0 >>but if the compatability.h wasn't altered then you can start jack as >>root with >>#jackd -R -v -d alsa -d hw:0 >> >> > >Though not mandatory but jack gets a bit more stressed if we connect clients >to it. I'll try an explanation for how to get a simple setup going. >With jack there are a few simple clients. I propose connecting jack_metro. >with: >$ jack_metro -b 100 >and then connect it to the jack soundcard output with: >$ jack_connect metro:100_bpm alsa_pcm:playback_1 > >this should result in a beeping sound at regular intervals. (extremely >annoying stuff) >In theory that should be enough to provoke the problems... Someone that has a >running kernel that actually is observing the problems, Glenn?, should try >this client-setup out and see if the problems occur with _it_ too. > With a jackstart -R -v -d alsa -d hw:0 -p 1024 I can get away with it If I just look at it (I'm in fluxbox). But If open/close mozilla (ie. do stuff) I get xruns. > > > >>There's an explanation of commnad line options at >>http://www.djcj.org/LAU/jack/ >> >>I think that's everything. >> >>I got xruns by opening programs but my audio tools are rezound and >>ardour and they won't record much longer that 20 seconds before jack xruns. >> >>I was the original poster. I found that if I used the 2.4.2 kernel with >>the low-latency patch from >>http://www.zip.com.au/~akpm/linux/schedlat.html#downloads and then >>installed jack as above, I would get NO xruns using kde, ardour (has >>multiple windows) and a network going. I've tried 2.6, 2.6.1 and patched >>to -mm4 and mm5 but I get xruns within even fluxbox by doing the most >>labour-unintensive computer tasks. >> >>The -p option extends the buffer (is that the word?). Well, I didn't >>need it with the 2.4.2 but in the 2.6 I made it -p 8192. It only >>extended the xrun relief by a couple of seconds though. (ie it did jack >>all) >> >> > >8192 samples at 48khz is an horrendously long time, over 150 ms... there must >be something we've missed, clearly this should be possible to handle? > >jack uses a rather clever ipc mechanism to contact all the clients with the >least amount of context switches, I remember there was some talk about 2.4 >having trouble with it at times... (preventing us from going to 64 >samples..kind of trouble)... >Could it be that some similar issue affects 2.6, but much worse ? But then >again, there are people running 2.6 with acceptable performance ??? >Just throwing out ideas... > >/Robert > > > >>If you could throw any light on this then that would be absolutely great. >> >> > > > > > >
