Hammerfall Low Latency and Xrun questions

Greetings people! :slight_smile:

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:

  1. Is this latency number true, or is there another way to determine what latency I get?

  2. 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.

Any clues?
.
.
.
My setup is:

— Hardware —
CPU: P4@3GHz Prescott w/ hyperthreading
M/B: Asus P4C800 Deluxe
RAM: 2Gb
AudioCard: Hammerfall PCI HDSP9652 + Focusrite Octopre Platinum
GFX: ATI Radeon 9550

— 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)

Thanks in advance!
Kle

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.

  1. Ignore it unless you can hear it.

  2. 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.

  3. 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).

Cheers! Pablo

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.

Cheers! Pablo

Hey!

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

Thanks Pablo!

Well,

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.

@Muadib

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.

@melkhorn

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!

Btw, thanks to all of you for helping me out! :slight_smile:

@Muadib

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.

   Seablade

why do you need so low a latency ? are you using software monitoring and using realtime software effects ?

The latency figure is correct, but excludes your hardware latency (jack only reports software latency).

UPDATE:

I just checked with ‘lspci -v’ that HDSP9652 has an IRQ 10.

These are also the devices with IRQ 10:

Ethernet
Firewire
Gfx Card
Smbus Controller
2x USB1 Controllers

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?

Ah, I see…

Is this normal? I mean, I expected this not to happen with the Hammerfall, or any other proffessional card…

One other question: I do it every time I record something, to that specific track, right?

…I feel such a function should be automated everytime a capture is done, if this is normal behaviour…

All best!
Kle

@Muadib

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.

  Seablade

@seablade

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:

@ 1024 frames (-p1024) = 2155 frames
@ 128 frames (-p128) = 358 frames
@ 64 frames (-p64) = 234 frames…and an XRun, LOL

Thank you for your responses, they’ve been really helpful! :slight_smile:

Cheers!
K.

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.

Cheers! Pablo

@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!

I hope I did right…

Thank you!

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”.

-Erdie