Re: Re: Starting playback in the middle of a movement

[Richard Shann]

On Sat, 2019-12-14 at 20:14 +0100, Andreas Schneider wrote:
> On 2019-12-14 12:27, Richard Shann wrote:
> > On Wed, 2019-12-11 at 11:34 +0000, Richard Shann wrote:
> > > > I get these two messages immediately when clicking playback
> > > > start.
> > > > The
> > > > sound starts considerably later.
> > > > 
> > > > > > independent of where the playback start marker is. Playback
> > > > > > ends
> > > > > > with
> > > > > > the message
> > > > > > 
> > > > > > Here endeth a scripted playback
> > > > > 
> > > > > Are you using JACK or Alsa?
> > > > 
> > > > I am using JACK.
> > > 
> > > Mmm, that's something that I have even less experience with -
> > > does it
> > > allow you to ask for messages to indicate when it does things -
> > > when
> > > it
> > > gets input? Did you upgrade to the latest Debian Stable? I
> > > haven't
> > > done
> > > that yet, which could account for the difference we are seeing.
> > > This is contingent on the old versions of Denemo showing the same
> > > behaviour (see below).
> > 
> > When writing that reply I was not thinking clearly enough: if you
> > are
> > getting a long delay when starting in the middle of a movement and
> > *not
> > *at the end then it must be that Denemo is doing something during
> > that
> > delay. What might work is to run it under the debugger and use
> > Control-
> > C to interrupt it during the long pause and then the command
> > "where" to
> > find out which function it is in at the time (then "continue" and
> > interrupt it again). Doing this a few times may show up some loop
> > in
> > the Denemo code (there will be more sophisticated ways of doing
> > this
> > I'm sure but this may do ...
> 
> Thank you for the suggestion. This is what I get:
> 
> #0  0x00007ffff5393819 in __GI___poll (fds=0x555555e5baa0, nfds=3,
> timeout=10)
>      at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007ffff626a136 in  () at /usr/lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x00007ffff626a4c2 in g_main_loop_run ()
>      at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007ffff6a61b15 in gtk_main ()
>      at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #4  0x00005555555ea26f in  ()
> #5  0x00007ffff7e25753 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #6  0x00007ffff7ed5250 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #7  0x00007ffff7ea716e in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #8  0x00007ffff7edf563 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #9  0x00007ffff7efe896 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #10 0x00007ffff7e301ab in scm_call_4 ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #11 0x00007ffff7ed50a6 in scm_catch_with_pre_unwind_handler ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #12 0x00007ffff7ed5328 in scm_c_catch ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #13 0x00007ffff7e255a2 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #14 0x00007ffff7e2586b in scm_c_with_continuation_barrier ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #15 0x00007ffff7ed201c in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #16 0x00007ffff7d54ef5 in GC_call_with_stack_base ()
>      at /usr/lib/x86_64-linux-gnu/libgc.so.1
> #17 0x00007ffff7ed2105 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #18 0x00007ffff7ed2145 in scm_with_guile ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #19 0x000055555557bd5a in main ()
> 
> Can you see therein what the problem may be?

No, this Ctrl-C has just interrupted some uninteresting part of the
loop - did you try it a few times to see if you could catch it doing
something else? If so I'll look into the code to find a few places to
try breaking in and finding whereabouts the long pause comes.

Richard