View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003207ardourbugspublic2010-05-29 08:572010-12-14 19:06
Reportercolinf Assigned To 
PrioritynormalSeveritymajorReproducibilityrandom
Status confirmedResolutionopen 
Product VersionSVN/2.0-ongoing 
Summary0003207: Ardour sometimes won't enter 'play'
DescriptionI've had this happen a few times: on starting ardour, the transport won't enter 'play'. I've seen it when 'Positional sync source' is set to 'internal': I haven't managed to reproduce it yet with this set to 'Jack', but it's a bit random so that might not mean anything.

When this happens, most controls in the UI are still responsive, but trying to close ardour causes it to freeze, and eventually the Gnome 'Ardour is not responding' dialog appears.

Anyone any ideas how to go about debugging this kind of thing?
Additional InformationThis is on Ubuntu 9.10, with ardour2 r7183, vanilla kernel 2.6.34, jack1 svn 4017.
TagsNo tags attached.

Activities

colinf

2010-05-31 14:41

updater   ~0008105

This was happening pretty regularly for me (once every 2 or 3 times I started ardour) on a 2.8GHz Pentium 4 desktop machine.

However, when I disable hyperthreading in the BIOS I'm unable to reproduce the problem.

Smells like some kind of deadlock to me. Would a backtrace be useful?

colinf

2010-06-03 12:48

updater   ~0008143

This occasionally happens while ardour is running too, even if it starts up OK.

2010-06-05 09:24

 

ardour-wont-play-bt (8,693 bytes)   

colinf

2010-06-05 09:27

updater   ~0008156

Just in case any wiser minds than mine can spot anything amiss, here's a backtrace of ardour when it's in the "stuck" state.

lincoln

2010-06-05 17:58

reporter   ~0008167

Came across this today on 2.8.9. I had ardour on sync Jack. Switched to internal and I could not engage play. Had to restart ardour.

cth103

2010-06-06 10:22

administrator   ~0008174

I can't get any insight from that trace; it may be necessary to do some printf debugging to see why the play isn't starting. If you can reproduce this fairly often you could perhaps put some debug output in to see how far ardour gets in trying to start playback...

colinf

2010-06-06 18:14

updater   ~0008177

Well, it looks like the Event::SetTransportSpeed that's queued in Session::request_transport_speed() is never seen by Session::process_event().

I can't yet see why this might be: I'll keep digging...

cth103

2010-06-06 23:57

administrator   ~0008178

Hmm; assuming the pending_events.write() in queue_event() is succeeding, I guess it would be interesting to see if process_with_events() is subsequently being called... if not I think it must be a deadlock in the process thread.

cth103

2010-06-07 12:57

administrator   ~0008180

I've just seen this on 3.0 too.

colinf

2010-06-09 16:55

updater   ~0008216

The pending_events_write() in queue_event() returns 1 whether or not ardour is "stuck", which I assume means it's succeeded.

When ardour is stuck, process_with_events() doesn't get called after this. In fact, it seems to only get called about nine times after startup, and then never again.

I can post a log of my debug output in the working and non-working cases, along with the patch to generate the output, if that's helpful.

2010-06-09 17:13

 

ardour-process-with-events-stuck.log (3,355 bytes)   

2010-06-09 17:14

 

ardour-process-with-events-good.log (5,667 bytes)   

2010-06-09 17:14

 

process-with-events-debug.patch (3,323 bytes)   

colinf

2010-06-09 17:19

updater   ~0008217

Sorry about the rather silly -good log format: I didn't want to chop out all of the process_with_events() trace output, though I realised as I hit upload that it's elmost entirely superfluous...

colinf

2010-07-01 11:24

updater   ~0008370

A few further observations, in case they help:

This bug seems to depend on jack's -p and -n settings: it happens much more at lower latencies.

It's also dependent on the number of plugins in the session: the more there are, the more often it happens. It seems not to be any specific plugin: the test session I've been using reproduces the bug 100% when Autotalent is enabled on one track, and less frequently when it is disabled, but I've observed the same bug with other sessions without that particular plugin.

paul

2010-07-02 21:08

administrator   ~0008375

believed fixed as of 7362 in ardour 2.X

colinf

2010-07-05 17:05

updater   ~0008397

Sorry to report that r7375 still exhibits the same problem for me here.

2010-07-05 17:55

 

r7361-bad.log (10,459 bytes)   

2010-07-05 17:56

 

r7361-good.log (808,716 bytes)

colinf

2010-07-05 18:08

updater   ~0008398

And here's the debug output from r7361, both in the case where the bug occurs, and a working run for comparison.

colinf

2010-12-14 19:06

updater   ~0009627

I've now observed that setting jackd timeout to 2000 mS ( -t2000 ) seems to prevent this bug from happening with a session and other jackd parameters that exhibit the bug 90% of the time with the default 500 mS timeout.

I don't know whether that's useful info for fixing the bug, or whether it even really is a bug at all rather than just user error, but I'm happy anyway now that I've found a workaround.

Issue History

Date Modified Username Field Change
2010-05-29 08:57 colinf New Issue
2010-05-31 14:41 colinf Note Added: 0008105
2010-06-03 12:48 colinf Note Added: 0008143
2010-06-05 09:24 colinf File Added: ardour-wont-play-bt
2010-06-05 09:27 colinf Note Added: 0008156
2010-06-05 17:58 lincoln Note Added: 0008167
2010-06-06 10:22 cth103 Note Added: 0008174
2010-06-06 18:14 colinf Note Added: 0008177
2010-06-06 23:57 cth103 Note Added: 0008178
2010-06-07 12:57 cth103 Note Added: 0008180
2010-06-07 12:57 cth103 Status new => confirmed
2010-06-09 16:55 colinf Note Added: 0008216
2010-06-09 17:13 colinf File Added: ardour-process-with-events-stuck.log
2010-06-09 17:14 colinf File Added: ardour-process-with-events-good.log
2010-06-09 17:14 colinf File Added: process-with-events-debug.patch
2010-06-09 17:19 colinf Note Added: 0008217
2010-07-01 11:24 colinf Note Added: 0008370
2010-07-02 21:08 paul Note Added: 0008375
2010-07-05 17:05 colinf Note Added: 0008397
2010-07-05 17:55 colinf File Added: r7361-bad.log
2010-07-05 17:56 colinf File Added: r7361-good.log
2010-07-05 18:08 colinf Note Added: 0008398
2010-12-14 19:06 colinf Note Added: 0009627