29 Mar
2010
29 Mar
'10
3:44 p.m.
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:
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.
On Sun, March 28, 2010 03:48, Tim E. Real wrote:
think
On March 27, 2010 07:54:21 pm Tim E. Real wrote:
As I reported, it was working fine for me using jack_transport, so I 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. 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 
29 Mar
29 Mar
5:18 p.m.
New subject: [Jack-Devel] Transport question
On Mon, Mar 29, 2010 at 2:41 PM, Tim E. Real <termtech(a)rogers.com> 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.
Which JACK server version are you using?
--
joq
6:07 p.m.
New subject: [Jack-Devel] Transport question
On March 29, 2010 05:18:28 pm you wrote:
On Mon, Mar 29, 2010 at 2:41 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Hi JOQ.
I'm currently using jackdmp-1.9.5 with ALSA backend
and QJackCtl-0.3.5.19
I think the problem also occurs while using Jack-1 + QJackCtl,
but I need to re-verify it on my end.
Thanks. Tim.
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.
Which JACK server version are you using? 
7:08 p.m.
New subject: [Jack-Devel] Transport question
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(a)rogers.com> 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
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
9:45 p.m.
New subject: [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:
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.
On March 29, 2010 05:18:28 pm you wrote:
> On Mon, Mar 29, 2010 at 2:41 PM, Tim E. Real <termtech(a)rogers.com> 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
30 Mar
30 Mar
4:01 a.m.
New subject: [Jack-Devel] Transport question
On Mon, 29 Mar 2010 21:42:47 -0400, "Tim E. Real" wrote:
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 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 :)
>
Tim, salsaman,
please, try today's svn trunk (qjackctl 0.3.6.4+), if you can
change-log says:
- Transport play (rolling) status is now being guarded to avoid
backfiring from extraneous transport state changes.
maybe it fixes the issue. i can't really verify whether it's actually on
target, as i fail to reproduce the reported behavior, both jackd 0.118.3
and 1.9.5 :/
you tell me.
thanks anyway.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org
5:53 p.m.
New subject: [Jack-Devel] Transport question
On March 30, 2010 04:01:54 am Rui Nuno Capela wrote:
On Mon, 29 Mar 2010 21:42:47 -0400, "Tim E.
Real" wrote:
Woo hoo! Got it!
Actually I fully anticipated what your fix would do:
On another box I had tested QJacjCtl-0.2.23
(before your ui button changes were made).
It never actually stopped, but I could briefly see 'starting'
in the status window and the 'pause' button would briefly go out,
but it would keep happily rolling.
So when I browsed your code in -0.3.5 and saw the button handling,
I knew that whereas -0.2.23 would say 'starting' but keep rolling,
-0.3.5 wanted to actually stop, and did so.
So now QJackCtl behaves like -0.2.23 did:
During the times when -0.3.5 wanted to stop, I instead now see 'starting'
in the status window and the 'pause' button will briefly go out,
but QJackCtl and the apps will keep happily rolling.
Even during the sometimes long pause where QJackCtl says 'starting'
the transports actually keep rolling in the apps and in QJackCtl.
Good.
Thanks a bunch Rui !
Will keep an eye out and report anything else.
Jack-devels: Apparently this closes the issue I reported months ago.
(Well, that is until I test with to-be-re-worked time-stretching
audio pre-fetch code in MusE again... But that's another story.
Hopefully it's solved.)
Cheers. Tim.
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 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 :)
Tim, salsaman,
please, try today's svn trunk (qjackctl 0.3.6.4+), if you can
change-log says:
- Transport play (rolling) status is now being guarded to avoid
backfiring from extraneous transport state changes.
maybe it fixes the issue. i can't really verify whether it's actually on
target, as i fail to reproduce the reported behavior, both jackd 0.118.3
and 1.9.5 :/
you tell me.
thanks anyway.
5147
days inactive
5148
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
3 participants
participants (
participants (3)
)
-
Jack O'Quin -
Rui Nuno Capela -
Tim E. Real
-
Jack O'Quin
-
Rui Nuno Capela
-
Tim E. Real