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
