I am recording a somewhat big (for me, at least) session on Ardour (34 tracks + 4 busses), and I get XRuns. I was wondering how people who own a Hammerfall audio card use it with Jackd for a stable, XRUN free recording session. Or, if you have certain jack parameters to recommendâŠ
I record Rock-Heavy Metal stuff, so I need to hear what I have recorded, since I do lots of overdubs.
When I record, I use Jack as:
jackd -R -dalsa -p64
however, this gives me Xruns, so I try -p128 some times. Jack says I have 1.3ms with -p64, and 2.7ms with -p128.
So here are my questions:
Is this latency number true, or is there another way to determine what latency I get?
Also, is there a difference if I run ardour + Jack as ROOT? My normal user account is set up to be in the @audio group, but I think I am having more XRuns as a single user.
â Software â
Distro: Gentoo (built with Pro Audio in mind, using audiodefâs guide, very helpful)
Kernel: 2.6.33.7-rt29
Jack: Jackdmp 1.9.5
Ardour: Ardourvst 2.8.11, (not emerged, compiled it myself)
Monitoring is listening to your own guitar through the speakers connected to the souncard while you are recording to ardour You can do it by software (by ardour) or by hardware (by the audio card itself). You can access the hardware mixer with software, by means of an alsa tool.
However, I donât think you need hardware monitoring if you are able to play the guitar normally with software monitoring, and actually succeed recording.
What you do is called overdubbing and you can take at least three different approaches to your âproblemâ of not alignment.
Ignore it unless you can hear it.
Search for nudge in the reference manual. Nudge backwards the captured track by about 190 periods if you are running with p=128. Measure the difference graphically, in frames. First mentally and then experimentally try to hear the temporal difference, between, say, a kick drum and a guitar if the hit with 3 or 4 ms of difference, in heavy metal music.
Set these 190 frames, or whatever is the difference that you find out, as the âInput latencyâ in qjackctl. You will probably see a better image.
Two notes, be aware of bug number 2798 (second highest zoom level is weird) and choose the -S option in the jackd command (synchronous mode, for jack2).
Ah OK, then you donât need a low latency setting in jack, do you? You monitor directly from your amp.
You can increase the period value to reduce drastically the probability of xruns, find out the offset after you record, write this value on the nudge clock below the secondary clock and nudge backwards with a click on the < button.
Actually, I am doing this at the moment while having the guitar amp in the same room, so I use semi-open headphones to listen to the mix coming to my ears.
What I am worried about is that the recorded stuff is a little delayed in regards to the already present mix, hence the latency questionsâŠso yep, I 'll try these suggestions and see what I can come up with
most of the time I am listening to what has been recorded to Ardour. Added to that, I use a Rocktron Intellifex for Reverb and Delay in my mix, so I often use side-chains from recorded tracks through Audio Outs to the unit and then back in through another pair of channels on my Interface, to a bus in Ardour.
The best solution would to use your HDSP9652 (via hdspmixer) for monitoring, which has essentially no latency. This is hardware monitoring, and along with ardourâs latency compensation, you could have software latency of 3 hours and everything would be fine (after you had several beers and a sandwich in the time youâd have to wait to play back what you had recorded).
That is unless, as Thorgal asked, youâre using realtime effects (from ardour/jack) on the source being recorded, as itâs being recorded. But you havenât answered that yet. So,are you?
Please clear up something else, too: are you getting xruns at -p128 and if not, is -p128 not low enough latency for you?
BTW, you can use jdelay to find out what latency your sound card is adding to your software latency.
No, I donât use realtime effects during recording. What I really encounter is this:
I record my guitar while listening to stuff I have already recorded on Ardour. (Isnât that software monitoring? Or what is the name? ). What I get is that the newly recorded stuff is slightly out of alignment with the previously recorded tracks.
I sometimes use the âClickâ feature of Ardour. But most of the time I use to record a hihat track from Hydrogen as metronome, but I hear that after a track has been recorded is is just slightly out of syncâŠ
That is why I want low latency, unless HDSP does that in a way I havenât figured out yet!
Really nothing there says you need low latency, as there is latency compensation that can be taken advantage of(Though is confusing to set up correctly right now apparently), however to answer your question yes I ran a RME HDSP for many years with <3mS software latency with no problems.
I applied a small script about latency changes at startup that I saw in another topic, and now my HDSP card has âlatency 255â while everything else has latencies 64 or 96.
Is this enough or should I physically swap my card through various PCI slots?
Note my first response in this thread. There is automated latency compensation, however setting it up correctly is confusing at the moment due to some issues in the system.
Ok, thanks for that. I guess Iâll have to wait for its implementation or a HOWTO about latency compensation, then.
UPDATE: I did a test by routing the HDSPâs L output into into one of the preampâs inputs, recorded it and measured the Sample difference at 3 period Jackd presets. Hereâs the result:
You have 2 x p + 105 (± 3) frames of latency. Those about 105 frames seem to be the hardware latency because it is the same number in the three cases.
On the other hand, jackd2 adds an extra period latency in the default mode. I guess that if you run jackd in synchronous mode (in the server path field of qjackctl, write jackd -S), you will have an offset of 1 x p + 105 frames instead. For example, for p = 1024, 1129. This is the behaviour of jack1 at least.
I suggest you try running âjackd -S -p1024 -i1129â (-i: input latency in qjackctl) and repeat the test.
@Pablo I tried the test again with âjackdk -S -dalsa -p1024 -I1129â but gave the same results, meaning the same number of samples needed to nudge the region into place. (The âIâ had to be capital, as I read on the manual, the small letter being mo. of input channels)
So, I played a bit more with Jack and I found exactly the option I was looking for:
âJackd -S -dalsa -p1024 -O2153â
As far as I know now, it is the output that I wanted to be delayed a bit, so that the input falls exactly into place. And it does!!! Now everything is aligned and in place, no need to nudge each captured region!
What you are planning to do should normally work - try to use irqbalance. I am using it and it is a part or portage. On my laptop, i can write about 40-50 tracks simulaneously without xruns. I guess you are running jack with realtime priority? If not, please do it. That is a âmustâ.