Now that we have built most needed software, we can begin to discover the GNU/Linux sound creation world. First I must say that I systematically use Jack to interconnect sotwares between them, even if most of them can run without Jack. It is a useful application that permits to play with almost everything that claim to be a Jack client (and all software here are Jack-compliant).
![]() | To know how to build Jack server, see Section 3.1. To know how to build Qjackctl, see Section 3.2. |
Setting Jack can be a nightmare, but sometimes it works more or less as you expected it to work (that is to say without too much xruns). We will not explain here what xruns are, it is enough to notice that they are bad. They must not appear while applications are running. But they can sometimes appear when you shutdown them. Not really bad in this case.
You can either execute Jack server as command line or use Qjackctl. I recommand using Qjackctl, for it makes connection/disconnection between Jack clients more simple. It you have chosen to use set_rlimits instead of Realtime LSM or PAM to manage realtime privileges access (see Section 1.4), do not forget to execute those applications prefixing them with set_rlimits -r.
Things like /usr/bin/jackd -R -dalsa -dhw:0 -r48000 -p128 -n2 should be reasonable. Adapt values to your hardware's configuration.
Read carefully the jackd manpage and do not hesitate to try different values, especially for the "Frame/Period" parameter (-p
command line argument):
-p, --period int Specify the number of frames between JACK process() calls. The default is 1024. If you need low latency, set -p as low as you can go without seeing xruns. A larger period size yields higher latency, but makes xruns less likely. The JACK capture latency in seconds is --period divided by --rate.
Now Jack is up and running.