View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002385 | ardour | bugs | public | 2008-09-07 16:37 | 2010-04-24 10:31 |
| Reporter | gabriel | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | SVN/2.0-ongoing | ||||
| Summary | 0002385: Ardour transport (wrongly) compensates 2 periods with software audio sources | ||||
| Description | When hooking up a software audio source to Ardour, and using the JACK transport, the software audio source appears 2 periods too early in the Ardour recording. One would expect it to start at the same time. This appears to affect several ardour versions, from the 0.99 series to the current stable release (2.4). To reproduce this bug: 1. Set up a JACK client audio source like this (supplied by Fons Andriaensen). It emits silence except for a single full-scale pulse every 24000 frames. int Jclient::jack_callback (jack_nframes_t nframes) { jack_transport_state_t state; jack_position_t posit; float *p; unsigned int k; state = jack_transport_query (_client, &posit); p = (float *) jack_port_get_buffer (_opport, nframes); memset (p, 0, nframes * sizeof (float)); if (state == JackTransportRolling) { k = posit.frame % 24000; if (k) k = 24000 - k; if (k < nframes) p [k] = 1.0f; } return 0; } 2. Set this client as the input to an Ardour track. Make sure that any latency compensation is turned off. 3. Set Ardour as JACK transport master and start recording. 4. Each pulse shows up 2 periods early. Frames do not align to N*22000. Note: This issue was originally reported on the jack-devel list between 8/26/08 and 8/29/08 on the thread titled "Interesting sync problem with Jack transport." | ||||
| Tags | No tags attached. | ||||
|
|
This issue was reported in 1742. |
|
|
in 1742 we were seeing 1 period of offset. here it seems to be 2. dpro reported on #ardour that the hydrogen issue is fixed when the jack-transport-start-at-zero.patch gets applied. |
|
|
While I do believe that this is a dup. of 0001742, I still have issues with Ardour 2.7.1. As you read... this may actually be a configuration issue -- but I'm finding that it's _hard_ to configure. :-) Even if "Auto Input" is disabled, ports are automagically connected whenever a track is added... and this appears to affect latency calcs. I did all these tests at 44,100 Hz (changing the code above to 22050 instead of 24000). ARDOUR AS JACK TRANSPORT MASTER OR SLAVE ======================================== * Audio is 5 periods ahead if a hardware port is accidentally connected and track is "align with existing material" * Audio is 4 periods ahead if the hardware port is diconnected and track is "align with existing material" * Audio is 1 period ahead if the hardware port is accidentally connected and track is "align with capture time" * Audio is correctly aligned if the hardware port is disconnected and track is "align with capture time" Note that "align with existing material" is the default setting for a track. Now... whether all this is a bug or a feature -- it's not very user-friendly and is an easy pit to fall in to. |
|
|
I discovered more oddness. The 4/5 period offset will happen in either case: * If Ardour's input is connected to a hardware input * If the software source of the audio is connected to a hardware output. (??!!) So, for instance, if the example client above (or a synth/sampler) is connected to the sound card outputs AND the track inputs for Ardour... it will give the 4/5 period offset. I started jackd with 4 periods per buffer for today's tests. I'm guessing that's where the 4-period offset comes from. The extra 1-period offset would seem to be the 'align with existing material' setting. |
|
|
a) auto-input has nothing to do with track-auto-connection. that is controlled via (1) the new session dialog (2) the preferences dialog. in general, a session created with this default setting will always connect track inputs automatically. b) when an ardour input is connected to multiple output ports, ardour will take the LARGER of the latencies associated with each port. since the software port has (probably) zero latency whereas the hardware port has (at least) 1 period latency, you will always get "skew" of recorded material if you are recording with this input configuration. its a mistake. either disable auto-connect (not auto-input) or manually disconnect h/w inputs. c) you should check what the align setting is for a correctly configured track - if it has only software sources, it should be "align with capture time" and all will work correctly. d) please feel free to suggest any ways to make this easier to configure for users. |
|
|
Thanks for the response, Paul. I don't quite understand (b), though. What I had was this (hope the ascii art works...): foo_out --+------- ardour:track_1_in | +------- hw:pcm_out This is what I meant by "if the software source of the audio is connected to a hardware output." It seems to me that this should not give me any extra skew. For me, it's enough if it's documented in the user docs on how to configure this stuff. When I ran in to trouble, that's the first place I looked. If you clear up (b) for me (and why that's a mistake to do) -- I would be happy to supply a documentation patch. I've pondered how to improve the UI and I've come up blank. :-) Thanks for asking. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-09-07 16:37 | gabriel | New Issue | |
| 2008-09-07 17:00 | lincoln | Note Added: 0005131 | |
| 2008-09-12 23:56 | torbenh | Note Added: 0005134 | |
| 2009-02-23 20:58 | gabriel | Note Added: 0005758 | |
| 2009-02-24 02:32 | gabriel | Note Added: 0005761 | |
| 2009-03-12 21:09 | paul | Note Added: 0005806 | |
| 2009-04-19 21:52 | gabriel | Note Added: 0005897 | |
| 2010-04-24 10:28 | cth103 | Category | bugs => bugs2 |
| 2010-04-24 10:31 | cth103 | Category | bugs2 => bugs |
