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/ |
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; > } -- Palimm Palimm! http://affenbande.org/~tapas/ |
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 |
In reply to this post by 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 |
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 |
In reply to this post by 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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
In reply to this post by Florian Paul Schmidt-2
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 |
>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 |
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 |
Free forum by Nabble | Edit this page |