Re: [LAD] [Jack-Devel] Transport question

On March 29, 2010 07:11:39 pm Rui Nuno Capela wrote:
> On 03/29/2010 11:05 PM, Tim E. Real wrote:
> > On March 29, 2010 05:18:28 pm you wrote:
> >> On Mon, Mar 29, 2010 at 2:41 PM, Tim E. Real <termtech@email-addr-hidden> wrote:
> >>> 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.
>
> nope, i just can't reproduce the behavior... but you might have a point
> re. play button checked state, which may be backfiring on
> JackTransportStarting...
>
> hmmm... i'll be back tomorrow :)
>
> seeya

Hey gang.

Sounds crazy, but definitely seems QJackCtl is interfering with
 transport somehow. Awfully sorry about all this, Rui.
I must investigate, it's an important thing...

More tests - Verified on two boxes with different sw versions:

* Tested with Jack-1 this time, instead of Jack-2 !

Using Jack-1, when QJackCtl is run all by itself, I could not get
 QJackCtl's own transport to exhibit the problem, like it did with
 Jack-2.

However, when I run the music apps with QJackCtl
 there is STILL definitely a problem as I reported earlier.
In that post, I reported Rosegarden, MusE, Ardour, and LiVES
 were ALL stopping with QJackCtl and Jack-2.
So now with Jack-1 and QJackCtl they STILL are.

Without QJackCtl (exact same command line jackd) the apps are rock solid
 no trouble even when MusE and Rosegarden are run together, with
 massive songs which have many tracks loaded.
MusE and RG both have their own transport panels with Jack transport
 support, and no matter how hard I tried, I could not get either one's
 'Play' or 'FF/REW' buttons to cause them to exhibit these problems.

Then, as soon as QJackCtl comes into the picture, presto!
They easily exhibit the problem by not starting, or stopping unexpected.
And QJackCtl's own transport also acts up in these cases.
Maybe it's a bad interaction between Jack and QJackCtl or
 something, but yep, there sure does seem to be a problem...

Verified on two boxes with different sw versions.

A more stark example:
When MusE and RG are running fine together with command line jackd,
 if I then run QJackCtl so that it picks up on the existing active running
 jackd (excellent new feature btw), then presto! The apps, and QJackCtl,
 immediately exhibit the problems! Strange, as if it interferes or something.

So Salsaman running Jack-1, won't see QJackCtl's transport by itself act up.
But as soon as you run your app with QJackCtl things act up, is that correct?

Thanks. Tim.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Mar 30 08:15:01 2010