jack transport oddness

[Florian Paul Schmidt-2]

Hi,

while playing around with jack_transport i wrote a small metronome
program which is supposed to be able to sync to jack_transport (while
ignoring, bpm and BBT from transport state as their meaning is not well
defined, but this will be subject of a future mail from me).

The process callback basically looks like this:

int process(jack_nframes_t frames, void* arg) {

        jack_position_t mypos;

        if (jack_transport_query(client, &mypos) != JackTransportRolling) {
                return 0;
        }

        // debug only. i know it's not RT :)
        std::cout << mypos.frame << std::endl;

        float *buffer = (float*)jack_port_get_buffer(out_port, frames);

        for (jack_nframes_t frame = mypos.frame; frame < mypos.frame + frames; ++frame) {
                if (frame % (jack_nframes_t)((double)jack_get_sample_rate(client)/(bpm/60.0)) == 0) {
                        buffer[frame - mypos.frame] = 1;
                        // std::cout << "click " << frame / (jack_nframes_t)((double)jack_get_sample_rate(client)/(bpm/60.0)) << std::endl;
                } else {
                        buffer[frame - mypos.frame] = 0;
                }
        }

        return 0;
}

which is pretty straightforward. Now the weird thing is that when i use
transport to locate to frame 0 and then start rolling (i.e. by using the
jack_transport program from the jack source distribution), my process
callback gets called with

(state == JackTransportRolling && frame == 0)

in two consecutive callbacks. This results in two metronome "ticks"
produced in the first two process callbacks after starting to roll.  

Example output (at period size 2048) looks like this:

0
0
2048
4096
6144
8192
10240
12288
14336
16384
18432
...

I attached a tarball with the complete sourcecode. You can also get it
here though:

http://www.affenbande.org/~tapas/wiki/admin.php?jack_transport_metro

Any thoughts?

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/

[Florian Paul Schmidt-2]

On Fri, 13 May 2005 14:21:09 +0200
Florian Schmidt <[hidden email]> wrote:

> int process(jack_nframes_t frames, void* arg) {
>
> jack_position_t mypos;
>
> if (jack_transport_query(client, &mypos) != JackTransportRolling) {

small error here. of course i need to zero out the buffer in this case.
new version uploaded and attached.

> return 0;
> }
>
> // debug only. i know it's not RT :)
> std::cout << mypos.frame << std::endl;
>
> float *buffer = (float*)jack_port_get_buffer(out_port, frames);
>
> for (jack_nframes_t frame = mypos.frame; frame < mypos.frame + frames; ++frame) {
> if (frame % (jack_nframes_t)((double)jack_get_sample_rate(client)/(bpm/60.0)) == 0) {
> buffer[frame - mypos.frame] = 1;
> // std::cout << "click " << frame / (jack_nframes_t)((double)jack_get_sample_rate(client)/(bpm/60.0)) << std::endl;
> } else {
> buffer[frame - mypos.frame] = 0;
> }
> }
>
> return 0;
> }

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/

[Florian Paul Schmidt-2]

On Fri, 13 May 2005 14:31:29 +0200
Florian Schmidt <[hidden email]> wrote:

> On Fri, 13 May 2005 14:21:09 +0200
> Florian Schmidt <[hidden email]> wrote:
>
> > int process(jack_nframes_t frames, void* arg) {
> >
> > jack_position_t mypos;
> >
> > if (jack_transport_query(client, &mypos) != JackTransportRolling) {
>
> small error here. of course i need to zero out the buffer in this case.
> new version uploaded and attached.

just to clarify: the original problem was orthogonal to this, and thus
persists..

flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Fri, 13 May 2005 14:21:09 +0200
Florian Schmidt <[hidden email]> wrote:

> while playing around with jack_transport i wrote a small metronome
> program which is supposed to be able to sync to jack_transport (while
> ignoring, bpm and BBT from transport state as their meaning is not well
> defined, but this will be subject of a future mail from me).

btw: i wrote this little program as a testing tool to find out about
jack_transport. The recent discussion on latencies of course also has an
impact on jack_transport.

Imagine two jack transport clients (A and B). A has its output routed
through a latent client C (not jack transport aware) and then to the
physical output ports. B is connected directly to the output ports.

Now let's assume for simplicity's sake that both A and B are not slow
sync client. Now the problem is:

The current semantics of the member frame of the jack_position_t type
when filled by jack_transport_query (which both A and B call during
their process callback) is (though mostly undocumented):

"the frame count of the first frame in the current process buffer"

We assume that transport is located to frame 0 and this is the first
process callback after we start rolling. Assuming furtherly that both
clients A and B have an internal timeline and output frames
corresponding to that timeline, they would both output those frames that
they would correlate to the time interval [0..periodsize/samplerate].
But since one of them is routed through a latent third client the frames
these two output will be audible at different times.

Now, with a working latency path traversal mechanism in jackd, client A
could find out that it has latency which is bigger than the physical
output latency alone and could compensate for this by internally
changing the mapping from the jack transport frame count to its internal
timeline. i.e. if the latency introduces by its path is N frames it
would output those frames that would correspond to the time

[0+N/samplerate..periodsize+N/samplerate]

and thus the two clients would be in sync again.

But here we see a problem already. Client A, if it wants to stay in sync
with other transport clients that are directly connected, has to exclude
the first N/samplerate seconds from its output to "catch up" to all
other nonlatent transport clients. This means, if A is i.e. a hd
recorder with a sound right at time 0s of its timeline, part of this
sound would never be audible (the first N/samplerate seconds).

So what to do about this? Personally i think jack_transport needs to be
changed to reflect this fact. IMHO clients need a way to tell jack
transport that their output is delayed by other clients [or internal
plugins, etc].

the jack_transport system then needs to start actually N frames earlier
than the relocatin point. In above case it would start with a negative
frame count in the position_t struct it passes to the clients.

transport clients that don't need to compensate can simply wait until
frame 0 comes along. Clients that do need to compensate would start at
the correct negative offset.

This implies that the clients _do_ need to know about the "real"
relocation point (in above case 0).

I don't know yet how to integrate this scheme best with current
jack_transport, but i think it would be important to not have any frames
dropped at transport start due to latencies in the signal paths of
transport clients.

What do you think?

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sat, 14 May 2005 00:55:07 +0200
Florian Schmidt <[hidden email]> wrote:

> [0+N/samplerate..periodsize+N/samplerate]

wrong "()":

[(0+N)/samplerate..(periodsize+N)/samplerate]

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sat, 14 May 2005 00:55:07 +0200
Florian Schmidt <[hidden email]> wrote:

> the jack_transport system then needs to start actually N frames earlier
> than the relocatin point. In above case it would start with a negative
> frame count in the position_t struct it passes to the clients.

the amount of frames it starts earlier is the maximum delay reported by
any transport client.

Flo

P.S.: is it bad style to reply so much to oneself? ;)

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[torbenh]

On Sat, May 14, 2005 at 01:03:41AM +0200, Florian Schmidt wrote:
> On Sat, 14 May 2005 00:55:07 +0200
> Florian Schmidt <[hidden email]> wrote:
>
> > the jack_transport system then needs to start actually N frames earlier
> > than the relocatin point. In above case it would start with a negative
> > frame count in the position_t struct it passes to the clients.
>
> the amount of frames it starts earlier is the maximum delay reported by
> any transport client.

just some info here. it seems strange to me though.

from libjack/client.c

                        if (control->process) {
                                if (control->process (control->nframes,
                                                      control->process_arg)
                                    == 0) {
                                        control->state = Finished;
                                }
                        } else {
                                control->state = Finished;
                        }

                        if (control->timebase_cb)
                                jack_call_timebase_master (client);

timebase master is called in the realtime thread after calling process()
i have not yet found where transport start stop is happening.
but i guess this is happening in jackd befoere starting the graph cycle.

generally the transport client is executed before the master
eg. sequencing synth -> ardour



> Flo
>
> P.S.: is it bad style to reply so much to oneself? ;)

if no one else replies, yes :)

> --
> Palimm Palimm!
> http://affenbande.org/~tapas/
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Jackit-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/jackit-devel
>

--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[torbenh]

On Sat, May 14, 2005 at 10:44:22PM +0200, [hidden email] wrote:
> On Sat, May 14, 2005 at 01:03:41AM +0200, Florian Schmidt wrote:
> > On Sat, 14 May 2005 00:55:07 +0200
> > Florian Schmidt <[hidden email]> wrote:

forget my last message.
this seems to be the style of this thread. :)
self replies

the problem appeared to me that transport_state is not double buffered
like the time info.

i still have 0.99.0 here shame on me
there was a fix for this. but florian still sees the bug.

i fixed it on 0.99.0 by setting transport_state == JackTransportStarting
even if there are no slowsync clients.

then the timebase latency of one period size is handled like slow_sync.
i only tested this using florians code and qjackctl which is not a
timbase_master.

i dont understand, why the fix jackd/transengine.c 0.18 -> 0.19 does
not fix florians problem.

using transportstarting seems to be the better fix for me.

transport guys please enlighten me.


--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sun, 15 May 2005 02:39:56 +0200
[hidden email] wrote:

> forget my last message.
> this seems to be the style of this thread. :)
> self replies
>
> the problem appeared to me that transport_state is not double buffered
> like the time info.
>
> i still have 0.99.0 here shame on me
> there was a fix for this. but florian still sees the bug.
>
> i fixed it on 0.99.0 by setting transport_state == JackTransportStarting
> even if there are no slowsync clients.
>
> then the timebase latency of one period size is handled like slow_sync.
> i only tested this using florians code and qjackctl which is not a
> timbase_master.
>
> i dont understand, why the fix jackd/transengine.c 0.18 -> 0.19 does
> not fix florians problem.
>
> using transportstarting seems to be the better fix for me.
>
> transport guys please enlighten me.

I'm not a transport guy, but i have the feeling that moving the
pending->current  update from jack_transport_cycle_end() to
jack_transport_cycle_start() could be another way to approach this. I
need to do more brainwrenching though..

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sun, 15 May 2005 15:19:10 +0200
Florian Schmidt <[hidden email]> wrote:

> I'm not a transport guy, but i have the feeling that moving the
> pending->current  update from jack_transport_cycle_end() to
> jack_transport_cycle_start() could be another way to approach this. I
> need to do more brainwrenching though..

No, this is wrong, too, i think..

The heart of the issue is that the timebase master provides timebase
info matching the current transport state. But this timebase info is
only available in the next process cycle, thus all these kind of weird
workarounds :)

quote from the JackTransport Design document:

"The timebase master registers a callback that updates position
information while the transport is rolling"

If it only does that while rolling it's already too late for the frame
== 0 case. It needs to produce the first timebase info while state is
still == starting.

Here's a scheme how it could work:

clients A B C, B is timebase master, C is slow sync clients

cycles 0..N-1:

  state == stopped, frame == 0

cycle N:

  state == stopped, frame == 0

  some client calls jack_transport_start() during cycle N

  state gets transitioned to starting (for next cycle)
  (in this scheme the state would have been transitioned to starting,
   even if there no slow sync clients, as the timebase master needs
   to be run during state == starting to produce info for the first cycle
   with state == rolling and frame == 0)

cycle N+1:

  state == starting, frame == 0

  timebase master produces timebase info for frame == 0
  (this is the important difference. The timebase master produces extended timing
   info for the first cycle when state == rolling. It needs to do this while
   the state is still staring, otherwise it would be too late)

  state stays starting as C is slow syncing (i.e. it needs one cycle)

cycle N+2

  state == starting, frame == 0

  timebase master produces timebase info for frame == 0

  state gets transitioned to rolling as C is done with slow syncing

cycle N+3:

  state == rolling, frame == 0

  timebase available for frame == 0

  timebase master produces timebase info for next cycle (frame == periodsize)

  frame += periodsize


cycle N+4:

  state == rolling, frame == periodsize

  timebase available for frame == periodsize

  timebase master produces timebase info for next cycle (frame == 2 * periodsize)

  frame += periodsize

cycle N+5:

  state == rolling, frame == 2*periodsize

  timebase available for frame == 2*periodsize

  timebase master produces timebase info for next cycle (frame == 3 * periodsize)

  frame += periodsize


Of course this would change the semantics of the timebase callback, but
it looks to me a bit more straightforward. This would also mean that for
every relocation the state would be == starting for a single period..

Here's some cycles of the current scheme (cvs jack) for your interest:

Clients A B C

B is timebase master

execution order A B C

no slow sync clients (different case than above, but this is where it
already breaks).

Process Cycle Overview:

- jack_transport_cycle_start

- A::process()

- B::process()

- B::timebase_callback()

- C::process()

- jack_transport_cycle_end

  - pending -> current

  - old_state = current_state

  - current_state transitions

  - advance frames if old state == rolling

  - update pending time base

Starting the Transport

- process cycles 0..N-1 before start request:

  state == stopped, frame == 0

- process cycle N:

  state == stopped, frame ==  0

  - sometime in process cycle N anyone client requests transport start

  - A::process()

  - B::process()

  - B::timebase callback()

  - C::process()

  - at end of process cycle N state goes to rolling (transition does _not_
    go through starting as we don't have slow sync clients)

- in process cycle N + 1:

  state == rolling, frame == 0 (so clients that ignore timebase think they
  already have to produce output. this is the actual bug i think)

  - A::process()

  - B::process()

  - B::timebase callback()

    - B's first opportunity to update the time base

  - C::process()

  - process cycle_end():

    - frame = pending.frame = 0

    - update state (stays rolling)

    - old_state == rolling and therefore:

         pending.frame = frame + periodsize (= periodsize)

- process cycle N+2:

  state == rolling, frame == 0 (ouch)

  A B and C process() (and B's timebase callback)

  - process cycle_end():

      frame = pending.frame (= periodsize)

    - update state (stays rolling)

    - old_state == rolling and therefore:

         pending.frame = frame + periodsize (= 2 * periodsize)

- process cycle N+3:

  state == rolling, frame = periodsize

  A B and C process() (and B's timebase callback)

  -process_cycle_end():

      frame = pending.frame (= 2 * periodsize)

    - update state (stays rolling)

    - old_state == rolling and therefore:

         pending.frame = frame + periodsize (= 3 * periodsize)


Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Jack O'Quin]

Flo,

On 5/15/05, Florian Schmidt <[hidden email]> wrote:
> On Sun, 15 May 2005 15:19:10 +0200
> Florian Schmidt <[hidden email]> wrote:
>
> > I'm not a transport guy, but i have the feeling that moving the
> > pending->current  update from jack_transport_cycle_end() to
> > jack_transport_cycle_start() could be another way to approach this. I
> > need to do more brainwrenching though..
>
> No, this is wrong, too, i think..

Unfortunately, I missed this entire thread.  I'd been totally consumed on
another project until Friday.  Then, my primary mail machine crashed hard
with a disk problem.  I'm reading mail from [hidden email] until I can
get that all sorted out.

Since I wrote the transport code, I probably need to understand this thread
from the beginning.  I'll check the list archives, but it might help for you to
summarize the problem and what you have discovered so far.

Sorry for the communications SNAFU.
--
joq


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
<a href="http://ads.osdn.com/?ad_ids93&alloc_id281&op=click">http://ads.osdn.com/?ad_ids93&alloc_id281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sun, 15 May 2005 10:33:32 -0500
Jack O'Quin <[hidden email]> wrote:

> Unfortunately, I missed this entire thread.  I'd been totally consumed on
> another project until Friday.  Then, my primary mail machine crashed hard
> with a disk problem.  I'm reading mail from [hidden email] until I can
> get that all sorted out.
>
> Since I wrote the transport code, I probably need to understand this thread
> from the beginning.  I'll check the list archives, but it might help for you to
> summarize the problem and what you have discovered so far.

Hi,

good to have you back. I was already worried that you were sick or
something.

As for a summary: I'm still trying to grok the transport code. The only
real observation i can make is that with my small jack transport
metronome (which i posted in this thread, too, and which i hope to use
as a testbed for some other transport ideas) i get state == rolling and
frame == 0 in two consecutive process cycles which clearly should not
happen (the code ignores the timebase info and just uses the frame
count).

This is with current cvs. jack 0.99 doesn't show this behaviour as
torben found out. This is due to a "fix" that was added somewhere
between these versions (see torben's mail). This fix delayed the
advancement of the transport frame for another cycle after transport
state changed to rolling.

imho this fixes the timebase case, but introduces a bug into the non
timebase case..

As for a way to do this correctly (especially with the constraint of no
extra context switches which forces the timebase callback to happen
somewhere in the process cycle) i'm not sure yet.

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Jack O'Quin]

On 5/15/05, Florian Schmidt <[hidden email]> wrote:

> On Sun, 15 May 2005 10:33:32 -0500
> Jack O'Quin <[hidden email]> wrote:
>
> > Unfortunately, I missed this entire thread.  I'd been totally consumed on
> > another project until Friday.  Then, my primary mail machine crashed hard
> > with a disk problem.  I'm reading mail from [hidden email] until I can
> > get that all sorted out.
> >
> > Since I wrote the transport code, I probably need to understand this thread
> > from the beginning.  I'll check the list archives, but it might help for you to
> > summarize the problem and what you have discovered so far.

> good to have you back. I was already worried that you were sick or
> something.
>
> As for a summary: I'm still trying to grok the transport code. The only
> real observation i can make is that with my small jack transport
> metronome (which i posted in this thread, too, and which i hope to use
> as a testbed for some other transport ideas) i get state == rolling and
> frame == 0 in two consecutive process cycles which clearly should not
> happen (the code ignores the timebase info and just uses the frame
> count).
>
> This is with current cvs. jack 0.99 doesn't show this behaviour as
> torben found out. This is due to a "fix" that was added somewhere
> between these versions (see torben's mail). This fix delayed the
> advancement of the transport frame for another cycle after transport
> state changed to rolling.
>
> imho this fixes the timebase case, but introduces a bug into the non
> timebase case..
>
> As for a way to do this correctly (especially with the constraint of no
> extra context switches which forces the timebase callback to happen
> somewhere in the process cycle) i'm not sure yet.

Thanks for the summary Flo, that is very helpful.  As you know,
the transport implementation is fairly compact, but has many
subtle sequencing and concurrency issues.

I read the rest of this thread in the archives, but was unable to access
the URL you posted for the test program.  Getting a copy of that to play
with is probably my first step.  Can you send me another URL?  This
one[1] wants a Wiki user name and password.

 [1]  http://www.affenbande.org/~tapas/wiki/admin.php?jack_transport_metro
 
--
 joq


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
<a href="http://ads.osdn.com/?ad_ids93&alloc_id281&op=click">http://ads.osdn.com/?ad_ids93&alloc_id281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Florian Paul Schmidt-2]

On Sun, 15 May 2005 11:57:11 -0500
Jack O'Quin <[hidden email]> wrote:

> I read the rest of this thread in the archives, but was unable to access
> the URL you posted for the test program.  Getting a copy of that to play
> with is probably my first step.  Can you send me another URL?  This
> one[1] wants a Wiki user name and password.
>
>  [1]  http://www.affenbande.org/~tapas/wiki/admin.php?jack_transport_metro

http://www.affenbande.org/~tapas/wiki/index.php?jack_transport_metro

Sorry. i was logged in as admin when i did c&p the URL..

Flo

--
Palimm Palimm!
http://affenbande.org/~tapas/


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Jack O'Quin]

On 5/15/05, Florian Schmidt <[hidden email]> wrote:

> On Sun, 15 May 2005 10:33:32 -0500
> As for a summary: I'm still trying to grok the transport code. The only
> real observation i can make is that with my small jack transport
> metronome (which i posted in this thread, too, and which i hope to use
> as a testbed for some other transport ideas) i get state == rolling and
> frame == 0 in two consecutive process cycles which clearly should not
> happen (the code ignores the timebase info and just uses the frame
> count).
>
> This is with current cvs. jack 0.99 doesn't show this behaviour as
> torben found out. This is due to a "fix" that was added somewhere
> between these versions (see torben's mail). This fix delayed the
> advancement of the transport frame for another cycle after transport
> state changed to rolling.

I'm having trouble figuring out what Paul was trying to fix when he
made that change.   I stared at those few lines of code for almost an
hour before I could see why it was broken.  It *looks* correct.  The
problem (as you noted) is that there is a time delay.  The frame number
being updated is for the *pending* cycle, not the next one we are about
to run.   Updating that based on the previous cycle's state is wrong.

I'm about to commit a change to back out Paul's fix.  That works correctly
for your test program.

The problem is, now I don't understand what he was trying to do in the
first place.  I vaguely recall it having something to do with not advancing
the frame number after we stop.  Can someone explain this, or better
yet provide a test case to demonstrate the bug?
--
 joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r 
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Paul Davis]

>The problem is, now I don't understand what he was trying to do in the
>first place.  I vaguely recall it having something to do with not advancing

http://sourceforge.net/mailarchive/message.php?msg_id=10202352


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel

[Jack O'Quin-2]

Paul Davis <[hidden email]> writes:

>>The problem is, now I don't understand what he was trying to do in the
>>first place.  I vaguely recall it having something to do with not advancing
>
> http://sourceforge.net/mailarchive/message.php?msg_id=10202352

Thanks for the pointer.

What I said in that thread was wrong.  The tricky part is that the
frame number being updated is *not* for the cycle that will follow,
but rather for the one after that (pending rather than current)...

        /* Update timebase, if needed. */
        if (ectl->transport_state == JackTransportRolling) {
                ectl->pending_time.frame =
                        ectl->current_time.frame + ectl->buffer_size;
        }

So, I need to understand what was causing ardour to be one period
behind jackd.  Does ardour read the state from its process thread?

After the transport stops, the next position you see will be one
period greater than the last one that actually played (normally).
That *should* be the exact frame number we will use for the first
buffer when we start rolling again (unless someone sets a new
location).  This seems to work, but I may be missing something still.
It definitely works for Florian's metronome program.
--
  joq


-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Jackit-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jackit-devel