When I record a first, then a second track, there is a delay when listening both together - probably the current 45 ms latency with my configuration.
My question is : is it possible to compensate it? The only solution I founded is to graphically move the recorded content to align the second with the first track.
Thank you in advance !
Some more comments:
It appears your version of jackd, however you got it (and it seems odd that you installed jackdmp to get jackd), is not compiled for SSE.
To compile jackd for sse, use --dynsimd on the ./configure line while compiling jack. The performance difference at extremely low period sizes (e.g: 64) is something of a wash, but it doesn’t seem to hurt.
other stuff that is useful when recording: mount your audio data disk with the options “defaults,noatime,nodiratime” in fstab.
Overall CPU usage doesn’t really matter much when trying to achieve low latency. It’s perfectly plausible to have cpu usage of 1% and still not be able to get low latency, or to have cpu usage of 70% AND be able to get low latency. There does seem to be a hard knee at about 80% of cpu, somewhat mitigated by having multiple cores available (not hyperthreading, sad to say).
I hope you enjoy 2.7ms of latency as much as I do.
Your startup session shows you are starting jack rather than jackdmp - which is a good thing. Just to verify: /mnt/ramfs should be a tmpfs filesystem. You can find that out by typing “mount” at the command line.
The jury is still out on the usefulness of hyperthreading. You might be able to get your interrupts to balance better by installing “irqbalance”, but that may be more of a AMDism.
I would recomend leaving usb2 entirely unused. If you have anything plugged into that port, plug it into one of your 3 other active ports. If you are out of ports, plug in a low usage device into that port.
as for chrt, you don’t want to boost the priority of qjackcontrol or jackd with that. (jackd does it for you via the -R option - mine is set to 87 however - any number greater than 52 is good) But you do want to boost the priority of the audio interrupt’s IRQ 18(ps aux | grep IRQ) via chrt -f 95 that_pidid.
(the rtirq script supposedly does this for you via calls to the pidof command)
As for actually seeing threads via the ps command - run “man ps” and look for the threading display options for your platform. Also, the top command, has a show threads option “H” while you run it.
Thank you for your help; I followed your advices :
- back to kernel 2.6.20-rt8
- recompile gpm, hal, das_watchdog, nvidia and alsa drivers, reboot
- uninstall jackdmp, jack-audio-connection-kit, reinstall jack-audio-connection-kit : unable to start jackd with less than 1024 samples buffer, and lot of strange messages.
- uninstall it, reinstall jackdmp :
19:10:43.526 JACK is starting…
19:10:43.532 jackd -R -P5 -p128 -dalsa -r48000 -p64 -n2 -D -Chw:0,0 -Phw:0,0 -i8 -o8 -H -M -I2 -O2
19:10:43.548 JACK was started with PID=27705 (0x6c39).
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK compiled with System V SHM support.
JACK tmpdir identified as [/mnt/ramfs]
loading driver …
apparent rate = 48000
creating alsa driver … hw:0,0|hw:0,0|64|2|48000|8|8|hwmon|hwmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 64 frames, buffer = 2 periods
ALSA: final selected sample format for capture: 32bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit little-endian
ALSA: use 2 periods for playback
19:10:45.632 Server configuration saved to “/home/eric/.jackdrc”.
19:10:45.634 Statistics reset.
19:10:45.637 Client activated.
19:10:45.641 Audio connection change.
19:10:45.655 Audio connection graph change.
JACK tmpdir identified as [/mnt/ramfs]
with 2.67 ms latency. It’s better ! CPU usage is about 4%.
The IRQs :
0: 133 0 IO-APIC-edge timer
1: 5502 0 IO-APIC-edge i8042
8: 2 0 IO-APIC-edge rtc
12: 190206 0 IO-APIC-edge i8042
14: 144766 0 IO-APIC-edge libata
15: 49217 0 IO-APIC-edge ide1
16: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
17: 424099 0 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb4, nvidia
18: 469361 0 IO-APIC-fasteoi uhci_hcd:usb2, hdspm
19: 494 0 IO-APIC-fasteoi ehci_hcd:usb5
20: 17811 0 IO-APIC-fasteoi acpi, eth0
NMI: 0 0
LOC: 1667164 1667128
But I’m not sure to understand the chrt command : ‘ps aux’ results :
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
eric 27688 2.2 2.1 22456 22456 ? SLl 19:09 0:19 qjackctl
eric 27705 2.7 1.9 20300 20380 ? SLsl 19:10 0:21 jackd -R -P5 -p128 -dalsa -r48000 -p64 -n2 -D -
chrt -p results :
chrt -p 27705
pid 27705’s current scheduling policy: SCHED_OTHER
pid 27705’s current scheduling priority: 0
chrt -p 27688
pid 27688’s current scheduling policy: SCHED_OTHER
pid 27688’s current scheduling priority: 0
Did you suggest me to increase this to 95 (‘chrt -f 95 27705’)?
Is there a problem to have IRQ 18 on both usb and hdspm? And do you know why CPU1 seems not to be used (it’s a Pentium 4 with hyperthreading)?
right clicking at the region, choosing ‘regionname-nudge-nudge bwd by capture offset’ should work too.
You can also change your region’s default alignment.
But why are you running at 45ms latency? no rt kernel?
more to the point, there should (almost) never be a need to do this. could you please describe the signal routing you were using? what were you recording? how was it connected to ardour?
Thank you for your help,
I’m using 2.6.21-rc5-rt4 kernel, with pam but as a beginner I’m not sure to have the right configuration to get a few ms latency values.
Alsa is 1.0.14-rc3, the only tha works fine with my AES 32 soundcard.
Jack is jackdmp but with the same configuration like the standard version, and the same latency value (45.7 ms with 1024 samples).
Under 1024 samples jack starts, then the CPU and xruns increase rapidly, then CPU use raises 100% and I have to kill the task with ps aux then kill (nr of the qjackctl task ).
Second answer : routing is instrument (bass, acoustic guitar) directly plugged in Soundcraft Ghost 32 -> Apogee Rosetta 800 -> AES 32 -> Jackdmp/alsa -> Ardour2
The sound I hear is not the output from AES 32, it’s the direct live sound for the instrument being recorded (due to latency value). Hearing the output of AES 32 the delay is too important, with my configuration I can’t monitor.
No problems of quality, the sound is perfect but when bass line is recorded, if I record guitar (live heared) when it’s finished, I listen the 2 tracks together : guitar is late compared to bass. That’s why I supposed that it’s a latency compensation problem?
thank you for your help to analyse this difficulties !
Well, there are quite a few tuning things you must do. That setup ought to be able to run at 64 samples/period at 44.1khz, 256, at the very least. You might want to try that with -n 3 (periods). I’m not huge on jackdmp in a non-multi-core situation. Is jack running with the -R (realtime) option?
First, which you are doing, is run an RT kernel. That’s an awfully new one, I’m still back at .20-rt8.
Second, you need to boost the priority of the audio interrupt. There’s a script that does this called rtirq, and see the howto at:
but as that’s not specific to your OS, basically you can find out the interrupt
your card is on via cat /proc/interrupts, then increase it to above the priority of your jackd process via:
chrt -f 95 that_irq_process_id
Please stop by the irc chat if you have further trouble.
There is an option in the right-click context menu of each track, something like “align recording with existing material /align with capture time” . You may want to make sure that this option is set correctly.
Although the above hints for obtaining low latency are of course very useful, I would like to point out that low latency is not a substitute for latency compensation (the functionality the original post was about). Even when latency is only a few milliseconds, when you do repeated overdubbing without latency compensation, the latencies can add up to audible (and annoying) asynchrony between tracks (I’m referring to the situation where you do your overdubbing listening to a previously recorded track, not to the click). Is there any reason why one should not apply latency compensation? Why not have perfectly synchronized tracks when you can?
Near-zero latency in an overdubbing situation is important only when you have a need to play back the captured signal in realtime (e.g. you want to apply effects to the captured signal and listen to it while you are recording it). When you don’t need this (e.g. you listen to the monitored version of the signal you are capturing), there is no need for low latency, and one could argue that high latency is preferable: 1. Although a system can be tuned for reliable performance with low latency settings, the same system with a high latency will be equally or more reliable (correct me if I’m wrong) 2. High latency allows for more realtime audio processing.
Just pointing out the obvious: Latency compensation is always on in Ardour. And at least I can’t think of any situation where the user would not want to use latency compensation - hence no control in Ardour to do that.
Yes, I always assumed that latency compensation is done automatically. That’s why I was puzzled when I found that with my new freebob driven soundcard, latency was not compensated. With this card I used a higher latency (p=2048) than before with my integrated soundcard, so when I heard the displacement of tracks, that made me suspect (wrongly) that the displacement had always been there and I just didn’t notice it due to small latency. The strange thing was that the align-to-capture-time option didn’t make any difference.
But it looks like a freebob/jackd issue. I tried high latencies with integrated card (alsa) and the problem was gone. I was using the freebob/jackd versions (1.0.0-3 and 1.102.20-1 respectively) that are in the Ubuntu Feisty repositories. Yesterday I tried jackd compiled from svn, and that solved the problem.
it may be that the freebob backend is not setting its port latency values correctly, which will lead to ardour not being able to compensate correctly.
I have the same problem, but in more simple situation. I recorde vie M-Audio USB FastTrack, routing the instrument being recorded directly to the track input, use hardware monitoring. It’s recorded with obvious latence.
I use ubuntu studio, rt-kernel, jack-0.116.1, ardour-2.8.3.
What could prevent ardour from correctly compensate the latence?
Funny story in the end:
I practised my guitar solo quite a lot, with metronome, becouse it’s difficult for me. Then I was quite proud of myself, then I can play it quite fine. Finaly, I tried to recorde it, but computer was recording with this latenci of about 80ms and i didn’t now that. As not using software monitoring, I didn’t care of latency. When I heard my takes, i almost tore my hears, how bad musician am I - I thought, its my fault, thet I just play always late.
Then my wife was recordig her sax solo, it was the same. She was quite upset. We thought, our concerts must be something awful, when we play so bad, out of rhythm.
Finaly our violinist, who is much better musician then us, was recording. First, she was also scared, but then she sad: no, I don’t play that bad. We recorded clic and it was obviously out of the grid.
We were quite pleased…
The click will record perfectly if you set up the inputs of the track you record on so that it only records the click. Most people just connect the click to a track that is already connected to some existing physical input on their audio interface - Ardour has to choose one or the other connection to determine what latency compensation to use, and it picks the largest latency which happens to be associated with the physical input. I have had to guide at least a dozen users through this “mistake” (its not really a mistake by anyone), and they miraculously get the click recording perfectly lined up with the grid.
You did not describe what led you to think that Ardour had placed your recorded material at the wrong point in time? What was it relative to?
We recorded first drums, bass and guitar in another daw and then imported it in ardour. Then we recorded our instruments with this playback. We didn’t play with the click. But compared with the playback our new tracks sounded always late.
Finaly i just placed one mic against loudspeaker and recorded click. I choosed to record the click this way, becouse it’s exactly the same way, how we recorded our insruments - via mic, sound card … And it was on the grid obviously late.
Do you set the hardware latency compensation when starting jack? You need to measure the latency induced by the hardware and let jack know about them so that the the whole system latency (software + hardware) is compensated for not just the software latency.
How can I set the hardware latency compensation when starting jack in qjackctl? But I think, the problem is caused by software latency. When decreasing periods/buffer an so decreasing software latency, the delay is smaller.