View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006887 | ardour | bugs | public | 2016-05-24 20:19 | 2017-06-10 16:28 |
Reporter | ovenwerks | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | confirmed | Resolution | open | ||
Platform | i5 pc | OS | linux | OS Version | ub 16.04 (xfce) |
Product Version | 4.7 | ||||
Summary | 0006887: Playhead stuck at play speed != 1.0 | ||||
Description | Playhead jumps to an old stop position and waits for audio to catch up if play speed is not 100% | ||||
Steps To Reproduce | play for 4 seconds stop shift back (rewind) to zero click on edge of "Sprung bar" box to go forward (I get 88%ish) Play head jumps to 4 sec and waits for audio to catch up. Also tried with: oscsend localhost 3819 /set_transport_speed f 1.01 with values from .5 to 8.0 every thing I tried fails except speed 1. | ||||
Tags | No tags attached. | ||||
|
I just tried to reproduce this with 5.4.252 and it seems like the behaviour of the shuttle control has changed and I can no longer reproduce. Can you still reproduce this issue with a recent/nightly build? |
|
Yes, I can still get this. There does have to be something in the session, something recorded in order for speeds other than 1.0 to work. I start with return to zero. play to some point, stop. use some method to rewind (shift left will work). then set speed to > 0 && != 1 using osc or the spring bar. (version 5.4-253-gf09e934) |
|
After a bit more effort I can reproduce the behaviour you describe. I noticed that if you use Shift + left arrow key twice to set the rewind speed != 100% then it seems to play back from the correct location. |
|
I was just about to report a new one, but it would probably be a duplicate of this one. I have a session with jack sync (Ardour is Time Master). I observe that the playhead is not in the actual position of Session::_transport_frame as long as _transport_speed == 0.0. With every change of the playhead position, the playhead is going to the position, of _transport_frame *before* the requested change. I put some couts into the source code to illustrate it. This is what happens when clicking into the ruler <mouse button press> EditorCursor::set_position () 2407164 <mouse button release> DEBUG::Transport: Request locate to 2407164 Session::start_locate() from 3782687 to 2407164 DEBUG::Transport: rt-locate to 2407164, roll 0 flush 1 loop-enabled 0 force 0 mmc 1 Session::locate () emit located Session::_transport_frame: 2407164, _engine.transport_frame(): 3782687 DEBUG::Transport: Butler transport work, todo = PostTransportLocate at 2703820154 DEBUG::Transport: nonrealtime locate invoked from BTW DEBUG::Transport: locate tracks to 2407164 Editor::located() _session->audible_frame(): 3782687 EditorCursor::set_position () 3782687 DEBUG::Transport: Butler transport work all done after 34815 usecs DEBUG::Transport: Frame 2407164 You see that Session emits located() when _transport_frame is already updated but _engine.transport_frame() not yet. Editor::located() asks for _session->audible_frame() which returns the obsolete _engine.transport_frame(). So the playhead ends up in the obsolete position. Sometimes (in my observations more likely using jack2 than jack1 and more likely using the dummy backend of jack) there is a request for forced locate following. That looks like this: <mouse button press> EditorCursor::set_position () 1110857 <mouse button release> DEBUG::Transport: Request locate to 1110857 Session::start_locate() from 1604571 to 1110857 DEBUG::Transport: rt-locate to 1110857, roll 0 flush 1 loop-enabled 0 force 0 mmc 1 Session::locate () emit located Session::_transport_frame: 1110857, _engine.transport_stream(): 1604571 DEBUG::Transport: Butler transport work, todo = PostTransportLocate at 2496451539 DEBUG::Transport: nonrealtime locate invoked from BTW DEBUG::Transport: locate tracks to 1110857 Editor::located() _session->audible_frame(): 1604571 EditorCursor::set_position () 1604571 DEBUG::Transport: Butler transport work all done after 8901 usecs DEBUG::Transport: Frame 1110857 DEBUG::Transport: Request forced locate to 1604571 DEBUG::Transport: rt-locate to 1604571, roll 0 flush 1 loop-enabled 0 force 0 mmc 1 Session::locate () emit located Session::_transport_frame: 1604571, _engine.transport_stream(): 1110857 DEBUG::Transport: Butler transport work, todo = PostTransportLocate at 2496494195 DEBUG::Transport: nonrealtime locate invoked from BTW DEBUG::Transport: locate tracks to 1604571 Editor::located() _session->audible_frame(): 1110857 EditorCursor::set_position () 1110857 DEBUG::Transport: Butler transport work all done after 9059 usecs DEBUG::Transport: Frame 1604571 DEBUG::Transport: Request forced locate to 1110857 DEBUG::Transport: rt-locate to 1110857, roll 0 flush 1 loop-enabled 0 force 0 mmc 1 Session::locate () emit located Session::_transport_frame: 1110857, _engine.transport_stream(): 1110857 DEBUG::Transport: Butler transport work, todo = PostTransportLocate at 2496536840 DEBUG::Transport: nonrealtime locate invoked from BTW Editor::located() _session->audible_frame(): 1110857 DEBUG::Transport: locate tracks to 1110857 DEBUG::Transport: Butler transport work all done after 8336 usecs DEBUG::Transport: Frame 1110857 Then we finally end up with playhead position and Session::_transport_frame matching. One more hint: When I click at the same ruler position twice the playhead is updated due to the click an actual adjustment of _transport_speed is not necessary as the position of the mouse coursor has not changed. However in that case, when I start the transport after the second click (by hitting Play) the playhead is not updated during transport like described in 0007084. UPDATE: This phenomenon is now addressed in https://github.com/Ardour/ardour/pull/345 Not sure if it's really related to the initially reported issue, though :( |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-05-24 20:19 | ovenwerks | New Issue | |
2016-11-02 00:35 | timbyr | Note Added: 0018900 | |
2016-11-02 00:35 | timbyr | Status | new => feedback |
2016-11-02 14:05 | ovenwerks | Note Added: 0018902 | |
2016-11-02 14:05 | ovenwerks | Status | feedback => new |
2016-11-02 14:06 | ovenwerks | Note Edited: 0018902 | |
2016-11-02 21:25 | timbyr | Note Added: 0018903 | |
2016-11-02 21:25 | timbyr | Status | new => confirmed |
2017-06-01 13:58 | johmue-eo | Note Added: 0019765 | |
2017-06-01 14:00 | johmue-eo | Note Edited: 0019765 | |
2017-06-01 18:35 | johmue-eo | Note Edited: 0019765 | |
2017-06-10 16:28 | johmue-eo | Note Edited: 0019765 |