View Issue Details

IDCategoryLast Update
0006887bugs2017-06-10 16:28
ReporterovenwerksAssigned To 
Reproducibilityalways 
Status confirmedResolutionopen 
Platformi5 pcOSlinuxOS Versionub 16.04 (xfce)
Product Version4.7 
Fixed in Version 
Summary0006887: Playhead stuck at play speed != 1.0
DescriptionPlayhead jumps to an old stop position and waits for audio to catch up if play speed is not 100%
Steps To Reproduceplay 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.

TagsNo tags attached.

Activities

timbyr

2016-11-02 00:35

developer   ~0018900

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?

ovenwerks

2016-11-02 14:05

reporter   ~0018902

Last edited: 2016-11-02 14:06

View 2 revisions

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)

timbyr

2016-11-02 21:25

developer   ~0018903

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.

johmue-eo

2017-06-01 13:58

developer   ~0019765

Last edited: 2017-06-10 16:28

View 4 revisions

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 :(

Issue History

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 View Revisions
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 View Revisions
2017-06-01 18:35 johmue-eo Note Edited: 0019765 View Revisions
2017-06-10 16:28 johmue-eo Note Edited: 0019765 View Revisions