Before I start to reply, I want to recommend to you the linux-audio-users and linux-audio-developers mailing lists. The djcj.org link you cite below *comes from* the homepages for these two mailing lists; "LAU" in the URL stands for linux-audio-users. Not to put this list down, but that's a better place for questions like yours in the future. Here in debian-user, it's probably a very very small fraction of the readership that has messed with this stuff; on the linux-audio-users mailing list, just about *everybody* has at one point or another. That said . . . On Sun, 23 May 2004 14:08:16 -0400 "Thomas H. George" <tomgeorge@spininternet.com> wrote: > > I am trying to get Jackstart working and get a message "cannot get > realtime capabilities, current capabilities are =ep cap_setpcap-ep > Probably running under kernel with capabilities disabled, a suitable > kernel would have printed something like =eip" > > My current kernel is 2.6.3 compiled with Preemptable Kernel enabled. At > www.djcj.org/LAU/guide I found the Low-Latency 2.4.x with ALSA HOWTO and > tried compiling a 2.4.3 kernel according to the instructions given but > could not find a Low latency scheduling option in Processor Types and > Features. > > I am using ALSA and a Soundblaster Live card and have no problem with > these - i.e. I can input the signal from an external phonograph, from > the computer's cdrom drive or from a wav file on the hard drive and the > output from any of these goes to my stereo system. > > I want to capture the phonograph output, remove cracks and clicks and > write the processed file to cd. > > I would appreciate any suggestions as to how to get Jackstart to work. OK, there are actually several different issues you raise here: preparing your kernel for low-latency work, preparing your kernel for JACK, and running the JACK server, jackd (in your case, through the intermediate program jackstart). PREPARING YOUR KERNEL FOR LOW-LATENCY WORK ------------------------------------------ 1. The procedures for preparing your kernel for low-latency are different for 2.4.x kernels and 2.6.x kernels. In the 2.4.x series, you have to patch the kernel source and recompile, using either Robert Love's preemptable kernel patch, or Andrew Morton's low-latency patch, or both. These two patches can coexist just fine, and most people have had best results patching with both; but there have been exceptions. If you want to make sure you get the best results, then you want to build a kernel with one, build a kernel with the other, build a kernel with both, and build a plain kernel with neither patch, and then do some latency testing of each and compare the results. But the point is that you have to patch the kernel source; you can't enable this stuff simply by selecting menu options in the kernel configuration process. These patches are available for Debian kernels: see for example the kernel-patch-2.4-lowlatency and kernel-patch-2.4-preempt packages. In the 2.6.x kernels, most of what these patches bought you in 2.4.x has been incorporated into the kernel source, so there's no need to patch the kernel. 2. Did you make a typo in your second paragarph above? Did you mean to say "2.4.3"? The 2.4.3 kernel is incredibly old, with a variety of issues/problems you don't want to deal with. The Debian packages for the two relevant kernel patches aren't going to work with a kernel that old; I think neither of them work with anything earlier than 2.4.18. Their package description pages will say. You do not want 2.4.3. 3. For low-latency work, you may not want a 2.6.x kernel. Amongst the linux-audio crowd, they're getting mixed reviews. One would think that incorporating the aspects of those two patches, as well as other speedups the 2.6.x series contains, would make it a slamdunk; but it ain't necessarily so, for reasons which I don't truly understand, not being a kernel hacker. If you're interested in this subject, see this thread from the LKML about pre-emption in the 2.6 kernels, and potential issues with it: http://kerneltrap.org/node/view/2702 I'd personally recommend building both a 2.4.20-something kernel and a 2.6.x kernel and testing both; but that's me. PREPARING YOUR KERNEL FOR JACK ------------------------------ 1. jackd does not *require* realtime capabilities. It works a lot better if it has them, but it does not require them. You have three choices in this regard: - forego realtime capabilities; - run jackd as root, since root has privileges to get realtime access; - Edit your kernel source to enable what's called "POSIX capabilities inheritance," which allows non-root user processes to obtain such privileged capabilities as realtime access. Each of these has its own drawbacks, and you've got to decide what's best for you. The con of the first is obvious: you don't get realtime capabilities, so your latency numbers will be higher and there's a higher likelihood of xruns. The con of the second is that if you're running jackd as root, all the other JACK clients that will establish connections with jackd *also* have to run as root. One hopes there aren't catastrophic bugs in any of them that will cause major problems when executed as root; but one never knows. And running your audio programs as root means root will own the files they write, etc.; so there often some hassle on the side with wanting to change file ownerships afterwards, so you can do subsequent non-JACK stuff as yourself rather than root, etc. The con of the third, enabling POSIX capabilities inheritance, is that it's a genuine security risk. It seems, from following conversations on linux-audio-user, that most people do the second; but a fair number of people do the third. Note that in the third case, I said "edit" rather than "patch". I am not aware of a kernel source patch to implement capabilities inheritance; I haven't seen one as a Debian package, as well. Somewhere on the LAU website, or linked-to from it, there's a page that tells you what files to edit, and how to edit them. All of this, incidentally, is explained in webpages linked-to from the LAU website whose URL you quoted; I encourage you to take the time to read that stuff, since most of what I or anyone else will tell you in answering your questions (like everything I'm saying here) is simply what *we* learned from taking the time to read it. RUNNING THE JACK SERVER ----------------------- There are three ways to start the JACK server, jackd: - invoking it manually, using the jackd command; - using the jackstart command; - using qjackctl, a GUI interface to jackd. jackstart is really only useful if you've modified your kernel to allow realtime capabilities inheritance. If you haven't so modified your kernel, it chokes, as you've noticed. If you're not going to modify your kernel, and instead are going to do your audio work as root, then running jackstart gives you nothing that running jackd manually doesn't give you. So, if you decide to not modify your kernel, then forget about jackstart and just run jackd instead. qjackctl is a very nice GUI interface to jackd. Apparently, you can fire it up, and then use it to start jackd; but I've had problems with that. I think it might use jackstart to start jackd, and since I haven't enabled capabilities inheritance, it fails. But if you've already started jackd manually, firing up qjackctl will cause it to connect to the running jackd and give you all kinds of information about it (xrun statistics, a very useful JACK client patchbay, etc.). I hope all this helps. Again, I encourage you to do some googling/ surfing on this stuff. -c -- Chris Metzler cmetzler@speakeasy.snip-me.net (remove "snip-me." to email) "As a child I understood how to give; I have forgotten this grace since I have become civilized." - Chief Luther Standing Bear
Attachment:
pgpB9xeeWs_jC.pgp
Description: PGP signature