View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000202 | ardour | features | public | 2003-12-30 16:37 | 2008-11-20 23:35 |
| Reporter | tuve | Assigned To | paul | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000202: output latency compensation | ||||
| Description | It seems that that ardour dosent take the output latency into considration when recording, this might be seen as a feature but for (I have noticed that per track compensation is on the wishlist) but for accuracy in a DAW an overall output latancy compensation is essential and it also provides a way for "not so hot" hardware to function with a lots of tracks and/or heavy effect load by increasing the buffer size/count in jackd and hardware or outboard monotoring, and the timing and sync will still perfect (the controlls will of course be slugish) | ||||
| Additional Information | I have verified this by: - recording the click output on track1 - routed track 1 to the physical output - connected my physical output to my physical input - recorded physical in on track 2 (track 1 output) it is actually more comlex than an overall output latancy compensation if one wants perfect sync because ardoura can have outboard inserts and sends etc but for basic functionallity atleast an automatic compensation when recording should be provided. | ||||
| Tags | No tags attached. | ||||
|
|
Reminder sent to tuve About this bug. You did not mention the version of ardour you have been using. The compensation feature you mention was committed to CVS several weeks ago. Please test the recent CVS or tarball snapshot to see if what you want is already done. jlc |
|
|
use a fresher version. the current beta9 tarball should have this.. |
|
|
Tuve - could you please report back on the status of this bug? It is believed fixed from 0.9beta9 onwards. THank you. |
|
|
I did some testing on 0.9beta10 myself, using a 48000Hz samplerate, 512 frames/period, 2 periods/buffer. * Recoding the click output directly on track1: This makes the clicks (visibly) match perfectly to the beats (the visible bars), but.. * Recording the click to track2 through hardware: ( click -> playback_1 -> external mixer -> capture_1 -> track2 ) This shifts every recorded click about 555 frames forward in time, so they no longer align with the beats. This doesn't seem right to me. Note: These 555 include the 42 mentioned below, so this brings it down to around 512. I think this might help :) * Recording track1 to track3 through hardware: ( track1 -> playback_1 -> external mixer -> capture_1 -> track3 ) This shifts the recorded clicks only 42 frames (=0.875 ms) forward in time, so the data in track1 and track3 aligns almost right. I guess this little delay is due to small input/output buffers in my soundcard (right ?), that jack/ardour doesn't know about. Would it be possible to eliminate this last latency by telling jackd about it through a command line option? A seperate latency-setting for input and output on each interface might be even better, though I don't think it would matter in my situation (just one soundcard). Tnx, vbloklnd |
|
|
your second case is correct - the click audio output is delivered to the h/w on one process cycle and isn't available to capture until the next process cycle. add the 42 frames of systemic latency, and you get 554 ... there is no software "workaround" for this - you are dealing with block-structured audio and this is how it works :) as for the 42 frames - i have long wanted to add a flag to the ALSA JACK driver/client to set this. it would add this to the port latency values it sets already. i just have never had to time, that's all. |
|
|
hmm. let me explain a little more. the reason for the difference between case 2 and case 2 is that click track runs *before* track2. JACK and ardour have no way of knowing that you have connected them. in the third case, you got lucky - track2 runs after track 1 and so you get "zero latency". if you try recording track2 to track1 via hardware, you'll find it works just like your second case. |
|
|
please comment on the bugnotes for this bug. i would like to close the bug or understand what i need to do to fix it. thanks. |
|
|
reporter has not replied to request for further comments. i believe this is not a bug. it does require careful user documentation, though. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2003-12-30 16:37 | tuve | New Issue | |
| 2004-01-03 19:51 | essej | Note Added: 0000335 | |
| 2004-01-03 19:52 | essej | Status | new => feedback |
| 2004-01-03 19:52 | essej | Additional Information Updated | |
| 2004-01-16 16:43 | mistatapas | Note Added: 0000348 | |
| 2004-02-11 19:35 | paul | Note Added: 0000406 | |
| 2004-02-18 15:14 | vbloklnd | Note Added: 0000449 | |
| 2004-02-18 15:21 | paul | Note Added: 0000450 | |
| 2004-02-18 15:23 | paul | Note Added: 0000451 | |
| 2004-04-14 04:16 | paul | Note Added: 0000622 | |
| 2004-05-16 22:09 | paul | Status | feedback => resolved |
| 2004-05-16 22:09 | paul | Resolution | open => fixed |
| 2004-05-16 22:09 | paul | Assigned To | => paul |
| 2004-05-16 22:09 | paul | Note Added: 0000747 | |
| 2008-11-20 23:35 | seablade | Status | resolved => closed |
