View Issue Details

IDProjectCategoryView StatusLast Update
0004956ardourbugspublic2016-11-23 00:27
Reportertimbyr Assigned To 
Status confirmedResolutionopen 
Target Version5.X git (version in description) 
Summary0004956: Playhead movement jerky at larger period sizes with internal sync
DescriptionWith large period sizes, for instance 4096 and 8192 frames the movement of the playhead is noticeably jerky.

This looks to be because when the session is set to internal sync Session::audible_frame does not account for time elapsed since the start of the processing period. The GUI may call Session::audible_frame two or three times in Editor::super_rapid_screen_update and gets the same value which gives the playhead a jerky appearance as it moves.

I've attached a patch which appears to fix the issue. I've just taken the frames since cycle start from the playback offset, so I think it should be correct for both forward and backward playback motion. I'm not sure if there are other things I'm not considering as to why this is an inappropriate fix etc.

There is also still an issue with the playhead jumping around a bit after this patch is applied, not sure what is going on there, I'll try to do a bit more thorough investigation when I get time.
TagsNo tags attached.


2012-06-27 11:58


smooth_playhead_large_period_sizes.patch (343 bytes)   
diff --git a/libs/ardour/ b/libs/ardour/
index 9dacdc3..ec6ff55 100644
--- a/libs/ardour/
+++ b/libs/ardour/
@@ -1245,6 +1245,7 @@ Session::audible_frame () const
 		tf = _engine.transport_frame();
 	} else {
 		tf = _transport_frame;
+		offset -= _engine.frames_since_cycle_start ();
 	ret = tf;


2012-11-14 03:55

administrator   ~0014252

re the attached patch:

Session::audible_frame() is used in various critical places,
most notably the MIDI Timecode Slave as well as the automation timers.

audible_frame() might be a misnomer, but changing this function should not be done lightly.

Generally on the right track, though. From a GUI perspective (Clocks, playhead etc.) _engine.frames_since_cycle_start () should certainly be added to the TF (or subtracted from the offset) when rolling forward.


2012-11-19 15:00

administrator   ~0014279

actually _engine.frames_since_cycle_start () is only meaningful when called from the jack process() callback.

In GUI context (drawing clocks, playhead) the number returned may not correspond to the session's current _transport_frame, jack_cycle(); although with jack2 it usually does.

To properly address this problem, ardour's session_transport needs to maintain its own time (using a DLL) to allow atomic queries of estimated audible_frame from every thread.


2016-11-23 00:27

developer   ~0019030

Confirming this issue is still present in the 5.X releases.

Issue History

Date Modified Username Field Change
2012-06-27 11:58 timbyr New Issue
2012-06-27 11:58 timbyr File Added: smooth_playhead_large_period_sizes.patch
2012-06-27 11:58 timbyr cost => 0.00
2012-06-28 11:54 cth103 Target Version => 3.0
2012-11-14 03:55 x42 Note Added: 0014252
2012-11-19 15:00 x42 Note Added: 0014279
2012-11-19 15:22 paul Target Version 3.0 => 3.X
2016-11-23 00:25 timbyr Status new => confirmed
2016-11-23 00:25 timbyr Target Version 3.X => 5.X git (version in description)
2016-11-23 00:27 timbyr Note Added: 0019030