Re: [LAD] [Jack-Devel] Transport question - Linux-audio-dev

29 Mar 2010

On March 29, 2010 03:46:00 am Rui Nuno Capela wrote:
...
  On Mon, 29 Mar 2010 02:42:12 +0200, salsaman(a)xs4all.nl
wrote:
  On Sun, March 28, 2010 03:48, Tim E. Real wrote:
  On March 27, 2010 07:54:21 pm Tim E. Real wrote:
  Hi list. Hi Salsaman.

 I built and installed Lives today. (Nice program!)

 I have now tested Lives, MusE, Rosegarden, and Ardour
  while running Jack-2.
 Each had blank default layouts, no tracks, except Lives
  which had one short video clip loaded.

 Guess what? They ALL stop unexpectedly at random times
  while rolling and hitting 'Rew' and 'FF' in QJackCtl.
 Even worse, they ALL fail to start sometimes when hitting 'Play'
  in QJackCtl, which is what Salsaman observed with Lives.

 However, I discovered that the problem depends on Jack
  buffer size (frames/period).
 With 1024 or 2048 for example, it happens very frequently.
 With 128, it happens very rarely.

 What's going on here? Clearly there's a problem.
 A setting? A bug? System issues?

 Thanks. Tim. 
 Oh no!
 I just tried some of the same tests *without* QJackctl
  and the problem disappeared.
 To see if the problem may just be more than one app running,
  I tried with MusE and Rosegarden running.
 Rock solid, no trouble so far.
 Strange considering QJackCtl is 'lightweight' compared to the others.

 I was sure that I tried this before without QJackCtl and it happened.

 Looks like this topic should move back to LAD now.
 Sorry for the noise. Will report back if anything changes,
  with my luck, it just might.

 Rui and Salsaman what do you think about all of this?

 Thanks. Tim. 
 As I reported, it was working fine for me using jack_transport, so I 
 think

  it is quite possible that something is going
wrong in qjackctl. It would
 be interesting to trace the jack calls in qjacktl to confirm whether or
 not it is sending the transport stopped messages, and if so figure out
 what is causing it to do so. 
 qjackctl issues jack_transport_stop() when you press its "pause" button.
 similarly, jack_transport_start() when you press the "play" button.
"rew"
 and "ffwd" buttons just do de/incremental jack_transport_locate()'s --
this
 has been like so and quite happily for way more than 5 years now :)

 it is funny that when you put lives in the picture and things behave
 strangely you infer that the problem is something else. you already made
 evidence that when *lives is not running* everything works as expected.

 imho, i'll reiterate that you should revise lives' jack_sync_callback,
 probably it is misunderstanding the jack transport sync api protocol,
 somehow.

 cheers 
Hi list, hi Salsaman, hi Rui.

Disturbing result: I discovered that QJackCtl, running all by itself
 with no other apps running, exhibits the problem.

Run QJackCtl.
Set the Jack size to a relatively high value like 1024 or 2048.
Now play the transport.
In the majority of attempts it will not start - goes into stop immediately.
If it does manage to start, try FF or REW. 
Again, in the majority of attempts it will stop.

Rui can you please take a look and try that simple test to verify?

I broke in with KDbg, and it is calling qjackctlMainForm::transportStop()

Looking at the stack trace, as far as I can tell:
It seems that in qjackctlMainForm::refreshStatus()
 in the line:
bool bPlaying = (tstate == JackTransportRolling || tstate == 
 JackTransportLooping);
bPlaying is false because the tstate is either JackTransportStopped
 (in the case of hitting play), or JackTransportStarting (in the case of
 hitting FF or REW while playing).

This eventually seems to cause the call to qjackctlMainForm::transportStop()
 via the line:
 m_ui.PlayToolButton->setChecked(bPlaying);

But I'm not sure because the stack trace is a bit hard to follow.

Maybe in the end it is a Jack or even a system problem, really I just want 
 to solve this. It's driving me nuts for months now.
So I need your help to identify where the problem lies. Is it Jack or what?

Thank you for your consideration.
Tim.