I am wondering whether using an old Audigy sound card might help with the xruns
I’ve been experiencing in playback/recording a 5 minute session. So far, I’ve
counted at least six varying from 0.7ms to 7.3ms. I’ve tried the rt kernel for
the setup, and it refuses to capture my Behringer C-1U mic on alsa_pcm (and I
haven’t a clue what to do about it). Without rt, it records OK. At this point,
I’m not even sure whether I have I set up the audio session properly.
I am confused at just what to adjust - I am concerned with the sudden ‘burps’ in
the recording (they are the xruns, right?)
I’m also confused whether I should even bother with the rt kernel, if I could
get rid of the ‘burps’ without using it. I’ve read a number of the posts, but it
seems to add more confusuion. Could someone help me get a better grip on what I
should do to be able to produce clean ‘unburped’ sound?
Basic needs here: stereo tracks for background, one mono voice track.
-n 3 is sort of important for intel chips, according to what users are reporting (it is the number of periods per buffer).
-R is for realtime mode. Don’t be fooled by the term “realtime”, it’s not exactly what this option is garantying. What it means here is that you allow jackd to access a privileged mode of operation (related to process scheduling).
If you as a user are allowed to do so can be checked or configured in /etc/security/limits.conf (see other discussion threads if you don’t know about this).
-P 70 is the priority level for the jackd audio thread (the higher the number the higher the priority). Don’t set it too high (like 99 or 100). There needs to be other things running at higher priorities than jackd. 70 is a good level for it.
I am currently using kernel 2.6.31.x (without any realtime patch on it, just the vanilla kernel and high resolution system timer) and I get outstanding performance with the -R mode. But you do need to set this up in /etc/security/limits.conf.
My laptop is an old Dell latitude D800, with an ancient intel chipset (ICH5). It can run at latency ~ 1ms for pure recording tasks (software effects is another thing though, as the CPU is only a pentium M at 1.6 GHz).
Thanks, Thorgal, for the explanation of the settings.
After resetting the settings in /etc/security/limits.conf and in Ardour ‘Audio
Setup’, I received this error message:
“cannot use real-time scheduling (FIFO at priority 10) [for thread 1740994286,
for thread 1740994286] (1: operation not permitted) cannot start engine”
So, I looked back in limits for a FIFO setting, and noticed there were default
settings (I’m not exactly sure whether I should disable or delete them):
Settings:
rtprio 0 // tried deleteing, and also resetting to 70: same error
nice 0 // tried deleteing, and also resetting to -19: same error
user is in audio group; checked uname -r: I’m using te rt kernel
Also, I will need to add ‘-C hw:1,0’ to capture the USB mic. Unfortunately, I
will need pulseaudio enabled in order to get any appareciable volume from the
Behringer C-1U mic.
What am I doing wrong? It seems the limits.conf isn’t set up correctly
I tried changing -n 3 with the plain (non-rt) kernel, experiencing no xruns (so far). Settings fo jackd are:
jackd - d alsa -n 3 -P hw:0,0 -C hw:1,0
that gives decent response with the USB mic when Ardour is loaded.
Using the rt kernel with the suggested settings, no xruns show up (so far), but the USB mic is non-operational. It supposedly connects, but output hovering way below -30db showing no response to vocal input (seems to be background connection noise that is showing on the meter).
Is there something I’m missing here with the rt kernel?