I don’t know about everyone else, but it seems like setting up JACK is like a hit and miss sort of deal, depending on your PC specs. I’m starting this thread to see what others are setting up as their basic JACK configurations. I think this will help n00bs tremendously, especially when it comes to figuring out how to minimize xruns and crashes.
I’d say it mostly depends on having a resonably good sound card (no Soundblaster, no integrated stuff [just as any gamer wouldn’t dream of firing up Counter Strike or Halo3 on their integrated Intel GFX]) a realtime kernel or the /etc/security/limit “hack” to get realtime privileges.
That said, my specs w/o xruns are:
AMD Athlon 2000+
1 GB RAM
openSUSE 11.0 w/ standard kernel, self compiled jack and Ardour
M-Audio Audiophile 2496
Apparently, 3rd party Audio cards make a huge difference. You both have killer JACK setups.
@ Peder,
Guilty… I’m mixing using onboard audio controller. I guess that’s why I have to set my FPP and Periods/Buffer so high. But, I don’t get that many xruns and seems pretty stable. My onboard is on an AMD 780G mobo, uses Realtek ALC889A spec (not sure what exactly that is, but supports HDMI out, so I would imagine 96khz, 24bit processing).
the chance is that it is the intel HDA chip. To be sure, check the alsa module:
lsmod | grep snd
if you see something like snd-hda-intel, then you’re not very lucky. If you confirm that, try a number of period = 3 (the ‘n’ jackd option) and set your sample rate to 48kHz. As far as I read here and there, a period size of 128 is OK with this chip. YMMV
Latency is really not the gymnastic event some make it out to be, It is always fun to push the envelope and see how far we can get away with something (like overclocking) but ultimately there is a point on the graph where things are as good as they need to be to work properly. Way back when I started computer recording I used a Turtle Beach Pinnacle sound card with Cubase VST, there was no ASIO driver so I had to run a buffer (or fpp) of minimum 5512 for smooth operation, but the setup was solid as a rock and worked great.
For example if you want to pipe your guitar through a simulator and record the simulated output to a track while playing back other tracks that have already been recorded then yes latency is important, same goes for playing keyboards through a softsynth etc. Our keyboardist uses my laptop via a Tascam US-122 with QSynth for one of his keyboards, even with a 512 fpp setting and 3 periods per buffer there is no audible latency, if there was it would certainly be noticed.
The point is that the importance of latency is only as important as your recording technique makes it, I think a lot of people (including myself) have been brainwashed into thinking that they MUST have an -rt Kernel or below 256fpp in order to use Linux as a viable DAW, in the real world that just isn’t the case. even something like hardware direct monitoring can make a huge difference.
Having said all that I’m curious if you are using the community MEPIS -rt Kernel or not. That alone could probably cut your fpp figure in half if you feel it’s necessary.
At last, someone who shares my view Latency IS important but understanding when it is important is even more important. I started doing audio on a PC (486 DX 33!) when you could just about do two channels and the latency was terrible by modern standards, but I learned how to work around it, the main thing was getting a setup that was stable enough not to go click and bang in the middle of recording.
After reading your initial thoughts on the intel module, I configured JACK to use a 512 buffer with 3 periods. The number of xruns on playback was horrible. So, I raised the buffer to 1024 again and things were good. I guess as long as I use a 1024 buffer, a setting of 3 or 4 periods makes no difference. Based on what you stated in your last post, it would appear that it really doesn’t matter if the buffer is high (for playback only… and that’s good news for me!!!). I had it stuck in my head that having these high settings was a very bad thing. I’m not as bad off as I thought. Thanks!
I’m not on my PC right now, but my other Mepis install (32-bit) has nothing but commented lines & examples in the limits.conf file. If they’re not there, should I just add them? Or, should I do something in qtJackctl first?
then you save the file. Be careful to respect the spaces on each side of the dash (except for the -19).
then, you log out and log in again. You should experience a certain improvement
If you don’t belong to a group audio, you can add yourself:
sudo adduser yourself audio
replace yourself by your login name
If there’s no group audio, it’s a bit more complex. try this stuff first and report.
I added those lines into my limits.conf file as well as verified I was already a member of the “audio” group. After logoff/login and a restart of JACK/Ardour… here’s what I got (and as you’ll see, not very good):
configuring for 44100Hz, period = 512 frames (11.6 ms), buffer = 3 periods
ALSA: final selected sample format for playback: 32bit little-endian
ALSA: use 3 periods for playback
19:46:23.201 Server configuration saved to “/home/Hippie/.jackdrc”.
19:46:23.206 Statistics reset.
19:46:23.213 Client activated.
19:46:23.217 JACK connection change.
19:46:23.222 JACK connection graph change.
Enhanced3DNow! detected
SSE2 detected
19:46:37.227 JACK connection graph change.
19:46:37.236 JACK connection change.
19:46:37.245 JACK connection graph change.
19:46:37.450 JACK connection change.
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:13.317 XRUN callback (1).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:17.310 XRUN callback (2).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:21.827 XRUN callback (3).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:24.854 XRUN callback (4).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:26.414 XRUN callback (5).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:27.967 XRUN callback (6).
19:47:28.281 XRUN callback (1 skipped).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:36.958 XRUN callback (7).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:47:39.005 XRUN callback (8).
**** alsa_pcm: xrun of at least 1234040204034.048 msecs
19:48:04.531 XRUN callback (9).
Interesting stuff, I’m using an emu 0404 on an amd athlon X2 2.4GHz, jackd -R -d alsa -n 2 -p 256 -r 48000
No xruns - ever
I have equally good results using an intel onboard chip, in theory there’s no reason why the onboard controllers should need larger buffer settings as long as the alsa driver is written properly. I have seen problems with full duplex mode with some chips, depends on them keeping their input/output pointers insync otherwise jackd will throw xruns in full duplex but may not in playback or capture only.
To all… thanks for the advice/tips. I truly don’t have a good understanding of all the aspects to recording and probably am a bit confused about latency.
You do have the snd-hda-intel module loaded. Try to set the period per buffer to 3, and see if you get a better experience at 48000Hz. Some onboard chips prefer this sample rate over all other possibilities (if they do provide other options).
As far as latency is concerned, unless you’re doing live performances or rely heavily on software monitoring with effect plugins as you play/record along your current session (and you may not have hardware monitoring possibility or h/w effects either), you simply can ignore the whole thing and set a large buffer size. Ardour compensate for it so things are kept aligned and on time. Personally, I use hardware monitoring (because my h/w provide it, not all h/w do that) and apply h/w effects as much as possible. My software effects are used during post-proc when latency does not matter at all. During mixing time, who cares about a low latency ?
Now, modern vanilla kernels are quite good for RT operations. I tried vanilla 2.6.28 and that was quite impressive. The RT patch does help though when low latency becomes critical and you need to have as much duration determinism as possible (realtime).
Peder said it: tick the realtime mode option and give a higher prio to the jack audio thread (70 or 80).
After that, here is my suggestion: switch to 48000Hz, and set the period size to 128 or 1024. I read that for some reason, the HDA chip works good with some but not others … go figure
OK… I’ll select the RT Mode when I get home and report the results.
Regarding the 48000Hz option. If I do that, Ardour will warn me that the tracks in my current project were recorded/assigned @ 44100Hz. For the sake of testing, though, I’ll create a new project and import one of the songs. If this works out to my advantage, I’ll start recording @ 48000, 24-bit moving forward.
