View Issue Details

IDProjectCategoryView StatusLast Update
0002385ardourbugspublic2010-04-24 10:31
Reportergabriel Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Product VersionSVN/2.0-ongoing 
Summary0002385: Ardour transport (wrongly) compensates 2 periods with software audio sources
DescriptionWhen 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."
TagsNo tags attached.

Activities

lincoln

2008-09-07 17:00

reporter   ~0005131

This issue was reported in 1742.

torbenh

2008-09-12 23:56

reporter   ~0005134

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.

gabriel

2009-02-23 20:58

reporter   ~0005758

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.

gabriel

2009-02-24 02:32

reporter   ~0005761

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.

paul

2009-03-12 21:09

administrator   ~0005806

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.

gabriel

2009-04-19 21:52

reporter   ~0005897

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.

Issue History

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