Re: Starting playback in the middle of a movement

[Richard Shann]

On Mon, 2019-12-16 at 19:39 +0100, Andreas Schneider wrote:
> On 2019-12-16 10:23, Richard Shann wrote:
> > On Sat, 2019-12-14 at 20:14 +0100, Andreas Schneider wrote:
> 
>  >> [...]
> > > 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.
> 
> I have tried it a few times, but haven't seen anything interesting.

This could be tricky to debug - the JACK backend is not something I
wrote, nor have I got a setup to use it. However we can try -
If you use Control-C to interrupt Denemo under gdb and then issue

b start_playing 
c

and the start play in the middle of a long piece it should hit the
breakpoint straight away. If not then I'll look into why not. But
assuming it does start straight away you can try the commands:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

b src/audio/jackbackend.c:200
commands
p playback_frame
c
end
c

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

and then start play - it should start spewing out frame numbers. The
interest would be if this does happen straight away and what happens
when playing actually begins. 


Did you manage to run any older version of Denemo that you know used to
work?

The emails to you are not being delivered again this morning - you will
need to check the list archive to see what I've sent :(


Richard



> 
> Example:
> 
> #0  0x00007ffff5392819 in __GI___poll (fds=0x5555571b5470, nfds=3,
> timeout=9)
>      at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007ffff6269136 in  () at /usr/lib/x86_64-linux-gnu/libglib-
> 2.0.so.0
> #2  0x00007ffff62694c2 in g_main_loop_run ()
>      at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007ffff6a60b15 in gtk_main ()
>      at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0
> #4  0x00005555555ea26f in  ()
> #5  0x00007ffff7e24753 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #6  0x00007ffff7ed4250 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #7  0x00007ffff7ea616e in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #8  0x00007ffff7ede563 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #9  0x00007ffff7efd896 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #10 0x00007ffff7e2f1ab in scm_call_4 ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #11 0x00007ffff7ed40a6 in scm_catch_with_pre_unwind_handler ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #12 0x00007ffff7ed4328 in scm_c_catch ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #13 0x00007ffff7e245a2 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #14 0x00007ffff7e2486b in scm_c_with_continuation_barrier ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #15 0x00007ffff7ed101c in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> --Type <RET> for more, q to quit, c to continue without paging--
> #16 0x00007ffff7d53ef5 in GC_call_with_stack_base ()
>      at /usr/lib/x86_64-linux-gnu/libgc.so.1
> #17 0x00007ffff7ed1105 in  () at
> /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #18 0x00007ffff7ed1145 in scm_with_guile ()
>      at /usr/lib/x86_64-linux-gnu/libguile-2.0.so.22
> #19 0x000055555557bd5a in main ()
> 
> As it's random when Ctrl-C is pressed, it is maybe easier to build on
> what we know. For instance, it is striking that the output always
> states
> that playback starts at 0.0. Can you recommend a place to set a
> breakpoint to debug that further?
> 
> Andreas