View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002017ardourbugspublic2008-01-10 22:092020-04-19 20:12
Reporterstigge Assigned Topaul  
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version2.1 
Summary0002017: [PATCH] ardour restarts/stops infinitely on reaching end marker
DescriptionHi,

to reproduce the problem, do the following:

* Open an actual project
* Activate the feature "Stop transport at session end"
* Get the "end" marker in sight, e.g. by zooming out
* Set the current position shortly before the end marker
* Play

Result:

The end marker is reached and the playing is stopped. But it is immediately resumed, only to be stopped again, etc. - infinitely, playing always some frames/milliseconds/whatever on each iteration, therefore even progressing a bit.

I looked into the code and found the following:

* Upon reaching the end marker, "_transport_speed" is set to 0, "stop_transport()" is done.
* Shortly afterwards, some event is handled to call "Session::follow_slave" which calls "start_transport()" upon "(slave_state == Running && _transport_speed == 0.0f)" which in turn sets "waiting_to_start = true;".
* "Session::process" gets called and with "waiting_to_start" calls "actually_start_transport()" which does what the name suggests.
* Now, the process loops, since the end marker seems to be reached still

I checked that both _transport_speed and waiting_to_start toggle their values between 0.0 and 1.0 resp. false and true.

Should the engine be halted completely upon reaching the end marker? Otherwise, the event loop is always running/called which has a strong tendency to (re-)start the transport all over the codebase. ;-)

Thanks,

Roland

PS: I'm not sure if this problem is somehow related to 0001991 since the reporter didn't write anything detailed.
TagsNo tags attached.

Relationships

related to 0001105 confirmed Transport conflict when Ardour is not the master 

Activities

paul

2008-01-13 14:25

administrator   ~0004652

if Session::follow_slave() is called, that would suggest that you have set Ardour to slave to some external transport source, most likely JACK. can you confirm this? i recall other reports of this behaviour confirmed that it went away if Ardour was not sync'ed to JACK.

stigge

2008-01-13 14:39

reporter   ~0004653

yes, setting "Positional sync source" to "Internal" makes the playback stop at the "end" marker. The "Time Master" setting (y/n) doesn't matter.

v2

2008-02-03 21:03

developer   ~0004698

what was the sync source originally? Were you really using that syncing method or was that misconfiguration?

stigge

2008-02-04 10:05

reporter   ~0004700

The sync source was originally JACK. I can reproduce the problem consistently, i.e. switching sync source to "JACK" makes it appear, switching to "internal" makes it disappear.

I don't know what you mean with "really using that syncing method", though. If I configure "JACK" or "internal" as syncing source, do I need to configure sth. to "really use it"?

v2

2008-02-04 12:11

developer   ~0004701

What I meant by "really using that syncing method" was that are you really syncing ardour to another piece of software?

Does the "time master" option (below the sync source combo) change ardours' behaviour in this situation?

stigge

2008-02-04 13:13

reporter   ~0004702

No, there was no other software to be synchronized to. But the "JACK" sync is the default and shouldn't lead to the described behaviour.

As written before, the "time master" setting doesn't change the behaviour.

Can't you reproduce the problem?

frubblezuck

2008-04-03 08:23

reporter   ~0004834

I'm not programmatically inclined. However, I have reproduced this issue with my set-up. I have ardour set to use JACK as its sync and with ardour as the time master, as well with "stop at session end" st. When the end marker is reached, the qjackctl log reports the below:

transport Starting, sync poll of 1 clients for 2.000000 secs
transport Rolling, 1.984001 sec left for poll
new transport position: 799104, id=0x43e
transport Starting, sync poll of 1 clients for 2.000000 secs
new transport position: 799872, id=0x43f
transport Starting, sync poll of 1 clients for 2.000000 secs
load = 14.5662 max usecs: 788.000, spare = 4545.000
transport Rolling, 1.984001 sec left for poll
new transport position: 799872, id=0x440
transport Starting, sync poll of 1 clients for 2.000000 secs
new transport position: 800640, id=0x441
transport Starting, sync poll of 1 clients for 2.000000 secs
transport Rolling, 1.984001 sec left for poll
transport command: STOP
transport Stopped
new transport position: 800640, id=0x442
load = 8.4363 max usecs: 123.000, spare = 5210.000
load = 5.3057 max usecs: 116.000, spare = 5217.000
load = 3.8248 max usecs: 125.000, spare = 5208.000
load = 3.4125 max usecs: 160.000, spare = 5173.000
load = 2.9532 max usecs: 133.000, spare = 5200.000
load = 2.7329 max usecs: 134.000, spare = 5199.000
load = 2.5197 max usecs: 123.000, spare = 5210.000
load = 2.7412 max usecs: 158.000, spare = 5175.000
load = 2.5988 max usecs: 131.000, spare = 5202.000
load = 2.4901 max usecs: 127.000, spare = 5206.000
load = 2.4451 max usecs: 128.000, spare = 5205.000
load = 2.5633 max usecs: 143.000, spare = 5190.000

and it rolls by pretty quick, so I apologize for not capturing it all. but it's clear at that point, ardour is sending rapid repetitive messages to jack to start again, with jack reporting in its logs of significant load increases. The start and stop transport buttons flash rapidly on the GUI and the overall performance of the machine begins to degrade.

As I am using hydrogen and other JACK-compat applications with ardour, I would prefer to be able to use JACK as the central timekeeper for my recording.

frubblezuck

2008-04-03 09:05

reporter   ~0004835

and that is ardour 2.4, kernel 2.6.24 with low latency options set, Slackware v12, and JACK 0.109.0. I updated a moment ago to JACK 0.109.2 with no change in behavior. Pretty sure whatever is happening is coming from ardour.

seablade

2009-07-05 01:56

manager   ~0006281

Looks like a version of this is still around, and seems to be related to 1105 as well.

seablade

2009-07-05 02:01

manager   ~0006282

Still around in 2.8 in one form or another. Added a relationship to an older bug report that pretty well describes the issue as well.

2009-10-19 23:57

 

2017.patch (1,223 bytes)    
diff --git a/libs/ardour/ardour/session.h b/libs/ardour/ardour/session.h
index dc9c470..ea461b5 100644
--- a/libs/ardour/ardour/session.h
+++ b/libs/ardour/ardour/session.h
@@ -1133,13 +1133,7 @@ class Session : public PBD::StatefulDestructible
 		}
 	}
 
-	bool maybe_stop (nframes_t limit) {
-		if ((_transport_speed > 0.0f && _transport_frame >= limit) || (_transport_speed < 0.0f && _transport_frame == 0)) {
-			stop_transport ();
-			return true;
-		}
-		return false;
-	}
+	bool maybe_stop (nframes_t limit);
 
 	bool maybe_sync_start (nframes_t&);
 
diff --git a/libs/ardour/session_transport.cc b/libs/ardour/session_transport.cc
index 3e370b1..a586a43 100644
--- a/libs/ardour/session_transport.cc
+++ b/libs/ardour/session_transport.cc
@@ -1349,3 +1349,17 @@ Session::reset_jack_connection (jack_client_t* jack)
 		js->reset_client (jack);
 	}
 }
+
+bool
+Session::maybe_stop (nframes_t limit)
+{
+	if ((_transport_speed > 0.0f && _transport_frame >= limit) || (_transport_speed < 0.0f && _transport_frame == 0)) {
+		if (synced_to_jack () && Config->get_jack_time_master ()) {
+			_engine.transport_stop ();
+		} else if (!synced_to_jack ()) {
+			stop_transport ();
+		}
+		return true;
+	}
+	return false;
+}
2017.patch (1,223 bytes)   

cth103

2009-10-19 23:58

administrator   ~0006747

Attached a patch which, AIUI, fixes this for 2.0. With the patch, stop-on-session-end is ignored if Ardour is synced to JACK and is not the master, but respected if synced to JACK when it is the time master.

paul

2009-10-30 16:51

administrator   ~0006996

committed rev 5983. confirmation of fix would be appreciated.

paul

2011-01-31 16:52

administrator   ~0010006

a year+ later, no confirmation. marking as resolved.

system

2020-04-19 20:12

developer   ~0021602

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2008-01-10 22:09 stigge New Issue
2008-01-13 14:25 paul Note Added: 0004652
2008-01-13 14:25 paul Status new => feedback
2008-01-13 14:39 stigge Note Added: 0004653
2008-02-03 21:03 v2 Note Added: 0004698
2008-02-04 10:05 stigge Note Added: 0004700
2008-02-04 12:11 v2 Note Added: 0004701
2008-02-04 13:13 stigge Note Added: 0004702
2008-04-03 08:23 frubblezuck Note Added: 0004834
2008-04-03 09:05 frubblezuck Note Added: 0004835
2009-07-05 01:55 seablade Relationship added related to 0001105
2009-07-05 01:56 seablade Note Added: 0006281
2009-07-05 02:01 seablade Note Added: 0006282
2009-07-05 02:01 seablade Status feedback => confirmed
2009-10-19 23:57 cth103 File Added: 2017.patch
2009-10-19 23:58 cth103 Note Added: 0006747
2009-10-19 23:58 cth103 Status confirmed => assigned
2009-10-19 23:58 cth103 Assigned To => paul
2009-10-19 23:59 cth103 cost => 0.00
2009-10-19 23:59 cth103 Summary ardour restarts/stops infinitely on reaching end marker => [PATCH] ardour restarts/stops infinitely on reaching end marker
2009-10-30 16:51 paul Note Added: 0006996
2011-01-31 16:52 paul Note Added: 0010006
2011-01-31 16:52 paul Status assigned => resolved
2011-01-31 16:52 paul Resolution open => fixed
2020-04-19 20:12 system Note Added: 0021602
2020-04-19 20:12 system Status resolved => closed