Muse and JackActivationCount errors

[Tim-442]

Hello, I've been so busy fixing Muse I am just now getting around
 to trying Muse with Jack 2. I thought I would ask here before
 attempting to fool around with the problems we're having...
 
We get errors like this:
JACK ERROR: JackActivationCount::Signal value = 0 ref = 4

Also, probably because of that error, we cannot move the Muse cursor,
 which calls jack_transport_locate().
After jack_transport_locate() is called, I see that the sync callback
 is NOT called.
I verified that with Jack 0.116.2, after jack_transport_locate() is called,
 the sync callback is in fact called.

I have replaced jack_client_new() with jack_client_open(), albeit  
 without any options.

Gotta be something simple... Can anyone help?
Thanks. Tim.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Fons Adriaensen-2]

On Sun, Jun 14, 2009 at 05:53:37PM -0400, Tim wrote:

> Hello, I've been so busy fixing Muse I am just now getting around
>  to trying Muse with Jack 2. I thought I would ask here before
>  attempting to fool around with the problems we're having...
>  
> We get errors like this:
> JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
>
> Also, probably because of that error, we cannot move the Muse cursor,
>  which calls jack_transport_locate().
> After jack_transport_locate() is called, I see that the sync callback
>  is NOT called.
> I verified that with Jack 0.116.2, after jack_transport_locate() is called,
>  the sync callback is in fact called.
>
> I have replaced jack_client_new() with jack_client_open(), albeit  
>  without any options.
>
> Gotta be something simple... Can anyone help?
> Thanks. Tim.

Can't help with this, but I've noticed a similar (but
probably unrelated) problem.

Alsaplayer with jack output works fine with 0.116, but
fails with 1.9.2. The error message seems to suggest
it sees a zero sample rate.

Ciao,

--
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

You know, other than that, I must say I am soooo happy with
 Jack2. Initial tests are remarkable - incredible !
For years I used Jack 1 and put up with shutdowns and sudden
 'buffer misaligns' (for lack of a better term) which caused distortion.
(Should'a seen me debugging Muse, looking at the process buffer
 pointers being passed by Jack to Muse, saying to myself "whaaa?"
 They seemed wrong, but what could I do? Other apps did it too...)
It'd be funny if there was actually some kind of fix for it
 I didn't know about...

Well, two nights with Jack2, hours of playing Muse 'Live' (no play/rec,
 until FF/REW is fixed) with MIDI keyboard and audio on an
 old Mandriva 2007.1 and no problems!
I sure hope it stays that way...

*** Thanks you guys! ***

Tim.
 
On Sunday 14 June 2009 18:45:52 Fons Adriaensen wrote:

> On Sun, Jun 14, 2009 at 05:53:37PM -0400, Tim wrote:
> > Hello, I've been so busy fixing Muse I am just now getting around
> >  to trying Muse with Jack 2. I thought I would ask here before
> >  attempting to fool around with the problems we're having...
> >
> > We get errors like this:
> > JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
> >
> > Also, probably because of that error, we cannot move the Muse cursor,
> >  which calls jack_transport_locate().
> > After jack_transport_locate() is called, I see that the sync callback
> >  is NOT called.
> > I verified that with Jack 0.116.2, after jack_transport_locate() is
> > called, the sync callback is in fact called.
> >
> > I have replaced jack_client_new() with jack_client_open(), albeit
> >  without any options.
> >
> > Gotta be something simple... Can anyone help?
> > Thanks. Tim.
>
> Can't help with this, but I've noticed a similar (but
> probably unrelated) problem.
>
> Alsaplayer with jack output works fine with 0.116, but
> fails with 1.9.2. The error message seems to suggest
> it sees a zero sample rate.
>
> Ciao,

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 14 juin 09 à 23:53, Tim a écrit :

> Hello, I've been so busy fixing Muse I am just now getting around
> to trying Muse with Jack 2. I thought I would ask here before
> attempting to fool around with the problems we're having...
>
> We get errors like this:
> JACK ERROR: JackActivationCount::Signal value = 0 ref = 4

This usually happens when the application audio cycle cannot complete  
in time (for whatever reason). Do you have a more complete log file to  
show?

Starting the server in verbose mode (- v ) can help understand what  
happens.

Where is the source code of Muse JACK module?

>
> Also, probably because of that error, we cannot move the Muse cursor,
> which calls jack_transport_locate().
> After jack_transport_locate() is called, I see that the sync callback
> is NOT called.
> I verified that with Jack 0.116.2, after jack_transport_locate() is  
> called,
> the sync callback is in fact called.
>
> I have replaced jack_client_new() with jack_client_open(), albeit
> without any options.
>
> Gotta be something simple... Can anyone help?
> Thanks. Tim.

A bug in transport has been fixed in SVN. Can you possibly test the  
SVN version and report?

See : http://jackaudio.org/download

Thanks.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 00:45, Fons Adriaensen a écrit :

> On Sun, Jun 14, 2009 at 05:53:37PM -0400, Tim wrote:
>
>> Hello, I've been so busy fixing Muse I am just now getting around
>> to trying Muse with Jack 2. I thought I would ask here before
>> attempting to fool around with the problems we're having...
>>
>> We get errors like this:
>> JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
>>
>> Also, probably because of that error, we cannot move the Muse cursor,
>> which calls jack_transport_locate().
>> After jack_transport_locate() is called, I see that the sync callback
>> is NOT called.
>> I verified that with Jack 0.116.2, after jack_transport_locate() is  
>> called,
>> the sync callback is in fact called.
>>
>> I have replaced jack_client_new() with jack_client_open(), albeit
>> without any options.
>>
>> Gotta be something simple... Can anyone help?
>> Thanks. Tim.
>
> Can't help with this, but I've noticed a similar (but
> probably unrelated) problem.
>
> Alsaplayer with jack output works fine with 0.116, but
> fails with 1.9.2. The error message seems to suggest
> it sees a zero sample rate.
>
> Ciao,
>

My understanding is that this issue is fixed in Alsaplayer SVN see:

http://alsaplayer.svn.sourceforge.net/viewvc/alsaplayer/trunk/alsaplayer/output/jack/jack.cpp?view=log

"Juuso Alasuutari: fix getting JACK sample rate"

Stéphane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 02:39, Tim a écrit :

> You know, other than that, I must say I am soooo happy with
> Jack2. Initial tests are remarkable - incredible !
> For years I used Jack 1 and put up with shutdowns and sudden
> 'buffer misaligns' (for lack of a better term) which caused  
> distortion.
> (Should'a seen me debugging Muse, looking at the process buffer
> pointers being passed by Jack to Muse, saying to myself "whaaa?"
> They seemed wrong, but what could I do? Other apps did it too...)

Hugh...., this seems weird. Again seeing the Muse JACK code would  
help...

Stephane


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 02:39, Tim a écrit :

> You know, other than that, I must say I am soooo happy with
> Jack2. Initial tests are remarkable - incredible !
> For years I used Jack 1 and put up with shutdowns and sudden
> 'buffer misaligns' (for lack of a better term) which caused  
> distortion.
> (Should'a seen me debugging Muse, looking at the process buffer
> pointers being passed by Jack to Muse, saying to myself "whaaa?"
> They seemed wrong, but what could I do? Other apps did it too...)
> It'd be funny if there was actually some kind of fix for it
> I didn't know about...
>
> Well, two nights with Jack2, hours of playing Muse 'Live' (no play/
> rec,
> until FF/REW is fixed) with MIDI keyboard and audio on an
> old Mandriva 2007.1 and no problems!
> I sure hope it stays that way...
>
> *** Thanks you guys! ***
>
> Tim.
>
> O

If I'm looking in the muse code (muse/driver/jack.cpp) as the right  
place, I can see that :

static void jack_thread_init (void* /*data*/)
       {
       doSetuid();
       if (jackAudio->isRealtime()) {
             struct sched_param rt_param;
             int rv;
             memset(&rt_param, 0, sizeof(sched_param));
             int type;
             rv = pthread_getschedparam(pthread_self(), &type,  
&rt_param);
             if (rv != 0)
                   perror("get scheduler parameter");
             if (type != SCHED_FIFO) {
                   fprintf(stderr, "JACK thread not running  
SCHED_FIFO, try to set...\n");

                   memset(&rt_param, 0, sizeof(sched_param));
                   rt_param.sched_priority = 1;
                   rv = pthread_setschedparam(pthread_self(),  
SCHED_FIFO, &rt_param);
                   if (rv != 0)
                         perror("set realtime scheduler");
                   memset(&rt_param, 0, sizeof(sched_param));
                   rv = pthread_getschedparam(pthread_self(), &type,  
&rt_param);
                   if (rv != 0)
                         perror("get scheduler parameter");
                   if (type != SCHED_FIFO)
                         fprintf(stderr, "JACK still not running  
FIFO !?!\n"
                         "======reliable RT operation not possible!!
======\n");
                   else
                         fprintf(stderr, "JACK thread succesfully set  
to SCHED_FIFO\n");
                   }
             }
#ifdef VST_SUPPORT
       if (loadVST)
             fst_adopt_thread();
#endif
       undoSetuid();
       }

So basically the Muse thread init callback starts to play with the RT  
thread parameters.... This is to avoided at  any price! NO APPLICATION  
IS EVER ALLOWED to play with those stuff. How do you think a system  
like JACK that is supposed to coordinate the proper functioning of a  
set of RT based audio application can deal with applications that  
start to do this kind of cray stuff on their own side?

So please remove this code then we can see if the problem you  
mentioned still persists.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[James Warden]

Ciao Stephane,

You mean: this is to be avoided _at all cost_ ;)

Cheers!
J.

--- On Mon, 6/15/09, Stéphane Letz <letz@...> wrote:

> From: Stéphane Letz <letz@...>
> Subject: Re: [Jack-Devel] Muse and JackActivationCount errors, also my COMPLIMENTS to the devels ...
> To: "Tim" <termtech@...>
> Cc: jack-devel@...
> Date: Monday, June 15, 2009, 5:47 AM
>
> Le 15 juin 09 à 02:39, Tim a écrit :
>
> > You know, other than that, I must say I am soooo happy
> with
> > Jack2. Initial tests are remarkable - incredible !
> > For years I used Jack 1 and put up with shutdowns and
> sudden
> > 'buffer misaligns' (for lack of a better term) which
> caused distortion.
> > (Should'a seen me debugging Muse, looking at the
> process buffer
> > pointers being passed by Jack to Muse, saying to
> myself "whaaa?"
> > They seemed wrong, but what could I do? Other apps did
> it too...)
> > It'd be funny if there was actually some kind of fix
> for it
> > I didn't know about...
> >
> > Well, two nights with Jack2, hours of playing Muse
> 'Live' (no play/rec,
> > until FF/REW is fixed) with MIDI keyboard and audio on
> an
> > old Mandriva 2007.1 and no problems!
> > I sure hope it stays that way...
> >
> > *** Thanks you guys! ***
> >
> > Tim.
> >
> > O
>
> If I'm looking in the muse code (muse/driver/jack.cpp) as
> the right place, I can see that :
>
> static void jack_thread_init (void* /*data*/)
>       {
>       doSetuid();
>       if (jackAudio->isRealtime()) {
>             struct
> sched_param rt_param;
>             int rv;
>            
> memset(&rt_param, 0, sizeof(sched_param));
>             int type;
>             rv =
> pthread_getschedparam(pthread_self(), &type,
> &rt_param);
>             if (rv != 0)
>                
>   perror("get scheduler parameter");
>             if (type !=
> SCHED_FIFO) {
>                
>   fprintf(stderr, "JACK thread not running SCHED_FIFO,
> try to set...\n");
>
>                
>   memset(&rt_param, 0, sizeof(sched_param));
>                
>   rt_param.sched_priority = 1;
>                
>   rv = pthread_setschedparam(pthread_self(),
> SCHED_FIFO, &rt_param);
>                
>   if (rv != 0)
>                
>         perror("set realtime
> scheduler");
>                
>   memset(&rt_param, 0, sizeof(sched_param));
>                
>   rv = pthread_getschedparam(pthread_self(), &type,
> &rt_param);
>                
>   if (rv != 0)
>                
>         perror("get scheduler
> parameter");
>                
>   if (type != SCHED_FIFO)
>                
>         fprintf(stderr, "JACK still not
> running FIFO !?!\n"
>                
>         "======reliable RT operation not
> possible!!======\n");
>                
>   else
>                
>         fprintf(stderr, "JACK thread
> succesfully set to SCHED_FIFO\n");
>                
>   }
>             }
> #ifdef VST_SUPPORT
>       if (loadVST)
>            
> fst_adopt_thread();
> #endif
>       undoSetuid();
>       }
>
> So basically the Muse thread init callback starts to play
> with the RT thread parameters.... This is to avoided
> at  any price! NO APPLICATION IS EVER ALLOWED to play
> with those stuff. How do you think a system like JACK that
> is supposed to coordinate the proper functioning of a set of
> RT based audio application can deal with applications that
> start to do this kind of cray stuff on their own side?
>
> So please remove this code then we can see if the problem
> you mentioned still persists.
>
> Stephane_______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

     
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Robert Jonsson]

Hi guys,

If I'm looking in the muse code (muse/driver/jack.cpp) as the right place, I can see that :

static void jack_thread_init (void* /*data*/)
     {
     doSetuid();
     if (jackAudio->isRealtime()) {
           struct sched_param rt_param;
           int rv;
           memset(&rt_param, 0, sizeof(sched_param));
           int type;
           rv = pthread_getschedparam(pthread_self(), &type, &rt_param);
           if (rv != 0)
                 perror("get scheduler parameter");
           if (type != SCHED_FIFO) {
                 fprintf(stderr, "JACK thread not running SCHED_FIFO, try to set...\n");

                 memset(&rt_param, 0, sizeof(sched_param));
                 rt_param.sched_priority = 1;
                 rv = pthread_setschedparam(pthread_self(), SCHED_FIFO, &rt_param);
                 if (rv != 0)
                       perror("set realtime scheduler");
                 memset(&rt_param, 0, sizeof(sched_param));
                 rv = pthread_getschedparam(pthread_self(), &type, &rt_param);
                 if (rv != 0)
                       perror("get scheduler parameter");
                 if (type != SCHED_FIFO)
                       fprintf(stderr, "JACK still not running FIFO !?!\n"
                       "======reliable RT operation not possible!!======\n");
                 else
                       fprintf(stderr, "JACK thread succesfully set to SCHED_FIFO\n");
                 }
           }
#ifdef VST_SUPPORT
     if (loadVST)
           fst_adopt_thread();
#endif
     undoSetuid();
     }

So basically the Muse thread init callback starts to play with the RT thread parameters.... This is to avoided at  any price! NO APPLICATION IS EVER ALLOWED to play with those stuff. How do you think a system like JACK that is supposed to coordinate the proper functioning of a set of RT based audio application can deal with applications that start to do this kind of cray stuff on their own side?

So please remove this code then we can see if the problem you mentioned still persists.

Due to the current release being stuck in a branch I believe this is the wrong code. Not that it matters much, the actual code is much the same.

If I recall correctly this actual code block was added many years ago due to some NPTL bug that was biting us.
jack insisted it was running realtime but the callback wasn't SCHED_FIFO.

The SCHED FIFO setting only occurs if jack insists it's running realtime but the thread is not SCHED_FIFO.
I guess by now we might as well remove the cludge, though unless jack2 has changed the thread scheduling it should not matter. (famous last words)

Regards,
Robert


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 14:03, Robert Jonsson a écrit :

> Hi guys,
>
>
> If I'm looking in the muse code (muse/driver/jack.cpp) as the right  
> place, I can see that :
>
> static void jack_thread_init (void* /*data*/)
>      {
>      doSetuid();
>      if (jackAudio->isRealtime()) {
>            struct sched_param rt_param;
>            int rv;
>            memset(&rt_param, 0, sizeof(sched_param));
>            int type;
>            rv = pthread_getschedparam(pthread_self(), &type,  
> &rt_param);
>            if (rv != 0)
>                  perror("get scheduler parameter");
>            if (type != SCHED_FIFO) {
>                  fprintf(stderr, "JACK thread not running  
> SCHED_FIFO, try to set...\n");
>
>                  memset(&rt_param, 0, sizeof(sched_param));
>                  rt_param.sched_priority = 1;
>                  rv = pthread_setschedparam(pthread_self(),  
> SCHED_FIFO, &rt_param);
>                  if (rv != 0)
>                        perror("set realtime scheduler");
>                  memset(&rt_param, 0, sizeof(sched_param));
>                  rv = pthread_getschedparam(pthread_self(), &type,  
> &rt_param);
>                  if (rv != 0)
>                        perror("get scheduler parameter");
>                  if (type != SCHED_FIFO)
>                        fprintf(stderr, "JACK still not running  
> FIFO !?!\n"
>                        "======reliable RT operation not possible!!
> ======\n");
>                  else
>                        fprintf(stderr, "JACK thread succesfully set  
> to SCHED_FIFO\n");
>                  }
>            }
> #ifdef VST_SUPPORT
>      if (loadVST)
>            fst_adopt_thread();
> #endif
>      undoSetuid();
>      }
>
> So basically the Muse thread init callback starts to play with the  
> RT thread parameters.... This is to avoided at  any price! NO  
> APPLICATION IS EVER ALLOWED to play with those stuff. How do you  
> think a system like JACK that is supposed to coordinate the proper  
> functioning of a set of RT based audio application can deal with  
> applications that start to do this kind of cray stuff on their own  
> side?
>
> So please remove this code then we can see if the problem you  
> mentioned still persists.
>
>
> Due to the current release being stuck in a branch I believe this is  
> the wrong code. Not that it matters much, the actual code is much  
> the same.
>
> If I recall correctly this actual code block was added many years  
> ago due to some NPTL bug that was biting us.
> jack insisted it was running realtime but the callback wasn't  
> SCHED_FIFO.
>
> The SCHED FIFO setting only occurs if jack insists it's running  
> realtime but the thread is not SCHED_FIFO.
> I guess by now we might as well remove the cludge, though unless  
> jack2 has changed the thread scheduling it should not matter.  
> (famous last words)
>
> Regards,
> Robert
>

In any case applications should never take this kind of decisions.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

Well, I removed the block completely, it ran,
 but same problem, no Muse cursor locate functions.
I even changed it to set the thread to SCHED_RR
 since that's what jackd is set at - it ran, but still no luck.

I found those same "JACK ERROR: JackActivationCount"
 errors in Rosegarden (old version) and Jack's own
 jack_test program.
Therefore since Rosegarden works fine,
 and I could see Jack locating properly etc.
 then I will assume the error has NOTHING to do with
 Muse's non-functioning cursor locate problem.
I will leave that particular error up to you folks...
 

So turning on verbose debug messages and running Muse I find this:

... All Ok up to here...
Jack: JackClient::Activate
Jack: JackClient::StartThread : period = 2666 computation = 0 constraint =
2666
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: JackClient::Init calling client thread init callback
JACK thread not running SCHED_FIFO, try to set...
JACK thread succesfully set to SCHED_FIFO
processSync audioState:1 frame:0
Jack: JackClient::kActivateClient name = MusE-1 ref = 4
Jack: JackClient::Init calling client thread init callback
Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.500_default_MusE-1 usec =
          2147483647 err = Interrupted system call
JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
...

Later, when Muse is running and I attempt to FF/REW I get this:
...
JackAudioDevice::seekTransport frame:96000
Jack: TransportLocate pos = 96000
Jack: RequestNewPos pos = 96000
JackAudioDevice::seekTransport frame:96000
Jack: TransportLocate pos = 96000
Jack: RequestNewPos pos = 96000
JackAudioDevice::seekTransport frame:96000
Jack: TransportLocate pos = 96000
Jack: RequestNewPos pos = 96000
...
(In other words it is TRYING to move, but the cursor,
 nor Jack's position, doesn't actually move or FF/REW etc.
 even when attempting this from QJackctl's FF/REW buttons).

Anyways, about that error shown above:
"Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.500_default_MusE-1 usec =
          2147483647 err = Interrupted system call "
This shows up many times, not just the one time shown, but only during
 startup. After Muse is running, when locating, they don't show up.
Could this error be the culprit?
I have played with Muse's Jack sync and process callbacks to monitor
 and make sure things are called and not failing, but no luck.

Maybe this JackFifo mechanism is expecting a call to jack_port_get_buffer()
 always NO MATTER WHAT during the process callback?
(Not able to tell at moment whether eventually it is called, I could check...)
Or else maybe we should switch to using Jack's thread facilities
 jack_client_create_thread() + friends.

Note that Muse actually runs fine otherwise, as I mentioned, audio + MIDI OK.

Thanks. Tim.
Hello Robert, nice to have you on board here.


On Monday 15 June 2009 08:03:33 Robert Jonsson wrote:

> Hi guys,
>
>
> If I'm looking in the muse code (muse/driver/jack.cpp) as the right place,
> I
>
> > can see that :
> >
> > static void jack_thread_init (void* /*data*/)
> >      {
> >      doSetuid();
> >      if (jackAudio->isRealtime()) {
> >            struct sched_param rt_param;
> >            int rv;
> >            memset(&rt_param, 0, sizeof(sched_param));
> >            int type;
> >            rv = pthread_getschedparam(pthread_self(), &type, &rt_param);
> >            if (rv != 0)
> >                  perror("get scheduler parameter");
> >            if (type != SCHED_FIFO) {
> >                  fprintf(stderr, "JACK thread not running SCHED_FIFO, try
> > to set...\n");
> >
> >                  memset(&rt_param, 0, sizeof(sched_param));
> >                  rt_param.sched_priority = 1;
> >                  rv = pthread_setschedparam(pthread_self(), SCHED_FIFO,
> > &rt_param);
> >                  if (rv != 0)
> >                        perror("set realtime scheduler");
> >                  memset(&rt_param, 0, sizeof(sched_param));
> >                  rv = pthread_getschedparam(pthread_self(), &type,
> > &rt_param);
> >                  if (rv != 0)
> >                        perror("get scheduler parameter");
> >                  if (type != SCHED_FIFO)
> >                        fprintf(stderr, "JACK still not running FIFO
> > !?!\n" "======reliable RT operation not
> > possible!!======\n");
> >                  else
> >                        fprintf(stderr, "JACK thread succesfully set to
> > SCHED_FIFO\n");
> >                  }
> >            }
> > #ifdef VST_SUPPORT
> >      if (loadVST)
> >            fst_adopt_thread();
> > #endif
> >      undoSetuid();
> >      }
> >
> > So basically the Muse thread init callback starts to play with the RT
> > thread parameters.... This is to avoided at  any price! NO APPLICATION IS
> > EVER ALLOWED to play with those stuff. How do you think a system like
> > JACK that is supposed to coordinate the proper functioning of a set of RT
> > based audio application can deal with applications that start to do this
> > kind of cray stuff on their own side?
> >
> > So please remove this code then we can see if the problem you mentioned
> > still persists.
>
> Due to the current release being stuck in a branch I believe this is the
> wrong code. Not that it matters much, the actual code is much the same.
>
> If I recall correctly this actual code block was added many years ago due
> to some NPTL bug that was biting us.
> jack insisted it was running realtime but the callback wasn't SCHED_FIFO.
>
> The SCHED FIFO setting only occurs if jack insists it's running realtime
> but the thread is not SCHED_FIFO.
> I guess by now we might as well remove the cludge, though unless jack2 has
> changed the thread scheduling it should not matter. (famous last words)
>
> Regards,
> Robert

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 15 juin 09 à 21:32, Tim a écrit :

> Well, I removed the block completely, it ran,
>  but same problem, no Muse cursor locate functions.
> I even changed it to set the thread to SCHED_RR
>  since that's what jackd is set at - it ran, but still no luck.
>
> I found those same "JACK ERROR: JackActivationCount"
>  errors in Rosegarden (old version) and Jack's own
>  jack_test program.
> Therefore since Rosegarden works fine,
>  and I could see Jack locating properly etc.
>  then I will assume the error has NOTHING to do with
>  Muse's non-functioning cursor locate problem.
> I will leave that particular error up to you folks...
>
>
> So turning on verbose debug messages and running Muse I find this:
>
> ... All Ok up to here...
> Jack: JackClient::Activate
> Jack: JackClient::StartThread : period = 2666 computation = 0  
> constraint =
> 2666
> Jack: Create non RT thread
> Jack: ThreadHandler: start
> Jack: JackClient::Init calling client thread init callback
> JACK thread not running SCHED_FIFO, try to set...
> JACK thread succesfully set to SCHED_FIFO

Could you *please* first *completely stop* calling this stupid  "set  
to SCHED_FIFO code" ?

> processSync audioState:1 frame:0
> Jack: JackClient::kActivateClient name = MusE-1 ref = 4
> Jack: JackClient::Init calling client thread init callback
> Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.
> 500_default_MusE-1 usec =
>           2147483647 err = Interrupted system call
> JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
> ...
>
> Later, when Muse is running and I attempt to FF/REW I get this:
> ...
> JackAudioDevice::seekTransport frame:96000
> Jack: TransportLocate pos = 96000
> Jack: RequestNewPos pos = 96000
> JackAudioDevice::seekTransport frame:96000
> Jack: TransportLocate pos = 96000
> Jack: RequestNewPos pos = 96000
> JackAudioDevice::seekTransport frame:96000
> Jack: TransportLocate pos = 96000
> Jack: RequestNewPos pos = 96000

Then I'll look at Muse transport code tomorow to see If i can find  
something.

Stephane

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

OK, removed sched block completely AND removed
 the call to jack_set_thread_init_callback().

Here's the whole output...

Start euid: 500 ruid: 500, Now euid 500
initJackAudio()
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_MusE-1
Jack: Already connected name = MusE-1
Jack: JackLibClient::Open name = MusE-1 refnum = 5
initJackAudio(): client MusE-1 opened.
initJackAudio(): registering client...
Jack: jack_set_graph_order_callback ext_client 83a1a40 client 83a1a40
Jack: SetGraphOrderCallback
global lib:       </usr/local/lib/muse>
global share:     </usr/local/share/muse>
muse home:        </home/col>
project dir:      <./>
user instruments: </home/col/muse_instruments>
scan ladspa plugin dir </usr/local/lib/muse/plugins>
scan ladspa plugin dir </usr/lib/ladspa/>
RemoteVSTClient: all cache files are up-to-date, not running scanner
scan ladspa plugin dir </home/col/.ladspa>
scan ladspa plugin dir </usr/local/lib/ladspa>
QtLibraryPath:
  </usr/local/lib/muse/qtplugins>
  </usr/lib/qt3/plugins>
  </usr/lib/kde3/plugins/>
  </home/col/.kde/lib/kde3/plugins/>
  </usr/lib/qt3/plugins/lib>
  </home/col/Source/muse-20090201-CVS-REL07-fresh/muse>
load user instrument definitions from </home/col/muse_instruments>
load instrument definitions from </usr/local/share/muse/instruments>
READ IDF /usr/local/share/muse/instruments/Roland-XP30.idf
READ IDF /usr/local/share/muse/instruments/Roland_FantomXR.idf
READ IDF /usr/local/share/muse/instruments/Roland-SCD70.idf
READ IDF /usr/local/share/muse/instruments/Korg-X50.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif-Rack.idf
READ IDF /usr/local/share/muse/instruments/emuproteus2000.idf
READ IDF /usr/local/share/muse/instruments/Access_Virus.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR530.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif.idf
READ IDF /usr/local/share/muse/instruments/Alesis-QS-78R.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-S90.idf
READ IDF /usr/local/share/muse/instruments/AlesisQS6.idf
READ IDF /usr/local/share/muse/instruments/ns5r.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR275.idf
READ IDF /usr/local/share/muse/instruments/xg.idf
READ IDF /usr/local/share/muse/instruments/MC505.idf
READ IDF /usr/local/share/muse/instruments/Korg-MS2000R.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-microQ.idf
READ IDF /usr/local/share/muse/instruments/MC303.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-Q.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-09.idf
READ IDF /usr/local/share/muse/instruments/Emu-4mbgsgmmt-sf.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetA.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetB.idf
READ IDF /usr/local/share/muse/instruments/Roland-E28.idf
READ IDF /usr/local/share/muse/instruments/Akai-SG01v.idf
READ IDF /usr/local/share/muse/instruments/gs.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-01v.idf
READ IDF /usr/local/share/muse/instruments/gm.idf
READ IDF /usr/local/share/muse/instruments/Waldorf_Microwave-I.idf
READ IDF /usr/local/share/muse/instruments/Hammond_XB-1.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-02.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P50m.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P100.idf
READ IDF /usr/local/share/muse/instruments/ZynAdd-1_4.idf
initMidiAlsa
ALSA port add: <Midi Through Port-0>, 14:0 flags 3 0x63
ALSA port add: <EMU10K1 MPU-401 (UART)>, 16:0 flags 3 0x7f
ALSA port add: <Emu10k1 Port 0>, 17:0 flags 1 0x42
ALSA port add: <Emu10k1 Port 1>, 17:1 flags 1 0x42
ALSA port add: <Emu10k1 Port 2>, 17:2 flags 1 0x42
ALSA port add: <Emu10k1 Port 3>, 17:3 flags 1 0x42
ALSA port add: <M Audio Delta 1010LT MIDI>, 20:0 flags 3 0x7f
ALSA port add: <qjackctl>, 128:0 flags 1 0xc2
ALSA port add: <System Announcement Reciever>, 129:0 flags 1 0xc2
Start thread Midi with priority 80
Trying RTC timer...
got timer = 57
Start thread Disc with priority 0
searching for software synthesizer in </usr/local/lib/muse/synthi>
7 soft synth found
starting with default template
Jack: JackClient::PortRegister ref = 5 name = MusE-1:Out 1-0 type = 32 bit
float mono audio port_index = 27
Jack: JackClient::PortRegister ref = 5 name = MusE-1:Out 1-1 type = 32 bit
float mono audio port_index = 28
watchdog set to SCHED_FIFO priority 99
Thread <Disc> set to SCHED_OTHER priority 0
Thread <Midi> set to SCHED_FIFO priority 80
Jack: JackClient::Activate
Jack: JackClient::StartThread : period = 2666 computation = 0 constraint =
  2666
Jack: Create non RT thread
Jack: ThreadHandler: start
processSync audioState:1 frame:0
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kActivateClient name = MusE-1 ref = 5
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kGraphOrderCallback
jack calling when audio is disconnected!
JACK: graph changed
Jack: JackClient::Connect src = MusE-1:Out 1-0 dst = system:playback_1
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kGraphOrderCallback
jack calling when audio is disconnected!
JACK: graph changed
Jack: JackClient::Connect src = MusE-1:Out 1-1 dst = system:playback_2
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kGraphOrderCallback
jack calling when audio is disconnected!
JACK: graph changed
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.500_default_MusE-1 usec =
  2147483647 err = Interrupted system call
jack calling when audio is disconnected!
JACK ERROR: JackActivationCount::Signal value = 0 ref = 5
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
JACK ERROR: JackActivationCount::Signal value = 0 ref = 5
jack calling when audio is disconnected!
JackAudioDevice::seekTransport frame:0
Jack: TransportLocate pos = 0
Jack: RequestNewPos pos = 0
lash_init: Not attempting to start daemon server automatically
JackAudioDevice::seekTransport frame:384000
Jack: TransportLocate pos = 384000
Jack: RequestNewPos pos = 384000
JackAudioDevice::seekTransport frame:384000
Jack: TransportLocate pos = 384000
Jack: RequestNewPos pos = 384000
JackAudioDevice::seekTransport frame:672000
Jack: TransportLocate pos = 672000
Jack: RequestNewPos pos = 672000
JackAudioDevice::seekTransport frame:672000
Jack: TransportLocate pos = 672000
Jack: RequestNewPos pos = 672000
JackAudioDevice::seekTransport frame:864000
Jack: TransportLocate pos = 864000
Jack: RequestNewPos pos = 864000


On Monday 15 June 2009 16:21:46 you wrote:

> Le 15 juin 09 à 21:32, Tim a écrit :
> > Well, I removed the block completely, it ran,
> >  but same problem, no Muse cursor locate functions.
> > I even changed it to set the thread to SCHED_RR
> >  since that's what jackd is set at - it ran, but still no luck.
> >
> > I found those same "JACK ERROR: JackActivationCount"
> >  errors in Rosegarden (old version) and Jack's own
> >  jack_test program.
> > Therefore since Rosegarden works fine,
> >  and I could see Jack locating properly etc.
> >  then I will assume the error has NOTHING to do with
> >  Muse's non-functioning cursor locate problem.
> > I will leave that particular error up to you folks...
> >
> >
> > So turning on verbose debug messages and running Muse I find this:
> >
> > ... All Ok up to here...
> > Jack: JackClient::Activate
> > Jack: JackClient::StartThread : period = 2666 computation = 0
> > constraint =
> > 2666
> > Jack: Create non RT thread
> > Jack: ThreadHandler: start
> > Jack: JackClient::Init calling client thread init callback
> > JACK thread not running SCHED_FIFO, try to set...
> > JACK thread succesfully set to SCHED_FIFO
>
> Could you *please* first *completely stop* calling this stupid  "set
> to SCHED_FIFO code" ?
>
> > processSync audioState:1 frame:0
> > Jack: JackClient::kActivateClient name = MusE-1 ref = 4
> > Jack: JackClient::Init calling client thread init callback
> > Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.
> > 500_default_MusE-1 usec =
> >           2147483647 err = Interrupted system call
> > JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
> > ...
> >
> > Later, when Muse is running and I attempt to FF/REW I get this:
> > ...
> > JackAudioDevice::seekTransport frame:96000
> > Jack: TransportLocate pos = 96000
> > Jack: RequestNewPos pos = 96000
> > JackAudioDevice::seekTransport frame:96000
> > Jack: TransportLocate pos = 96000
> > Jack: RequestNewPos pos = 96000
> > JackAudioDevice::seekTransport frame:96000
> > Jack: TransportLocate pos = 96000
> > Jack: RequestNewPos pos = 96000
>
> Then I'll look at Muse transport code tomorow to see If i can find
> something.
>
> Stephane

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

On Monday 15 June 2009 04:42:32 you wrote:

> Le 15 juin 09 à 02:39, Tim a écrit :
> > You know, other than that, I must say I am soooo happy with
> > Jack2. Initial tests are remarkable - incredible !
> > For years I used Jack 1 and put up with shutdowns and sudden
> > 'buffer misaligns' (for lack of a better term) which caused
> > distortion.
> > (Should'a seen me debugging Muse, looking at the process buffer
> > pointers being passed by Jack to Muse, saying to myself "whaaa?"
> > They seemed wrong, but what could I do? Other apps did it too...)
>
> Hugh...., this seems weird. Again seeing the Muse JACK code would
> help...

If I may be very specific, if it helps...
With Jack '1', all of a sudden there will be distortion in audio output.
My tests seemed to indicate that Jack was giving the app the wrong
 port playback buffer pointers. The app would 'dutifully' fill each buffer,
 but what came out of Jack was badly distorted sound - the wrong data.
By selecting a very long Jack buffer period of 4096 and a low
 sample rate, I was able to hear that each data buffer being played
 was in fact partially correct, but the last (or first) small portion of the
 buffer was not correct, hence with a short buffer size it sounds really bad.
I verified the data blocks filling the buffers were correct and CONTIGUOUS
 (no gaps) !

Any thoughts on what's going on there?
I am sure I've heard other apps do it too, but It's been a while since
 I tried them. I have two different sound cards and it does it on both.
With Jack '2' everything is fine so far. Nothing else changed...

Tim.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

After removing the scheduling code, I tried Muse again
 with Jack '1'.
Seems very stable now - so far no shutdowns or buffer problems,
 no matter how hard I tried. Usually it is quite easy to cause.
I guess that was the fix I've been looking for for years !
Will keep testing, but looks good...

Thank you very much for that!
Tim.

On Monday 15 June 2009 17:41:46 Tim wrote:

> On Monday 15 June 2009 04:42:32 you wrote:
> > Le 15 juin 09 à 02:39, Tim a écrit :
> > > You know, other than that, I must say I am soooo happy with
> > > Jack2. Initial tests are remarkable - incredible !
> > > For years I used Jack 1 and put up with shutdowns and sudden
> > > 'buffer misaligns' (for lack of a better term) which caused
> > > distortion.
> > > (Should'a seen me debugging Muse, looking at the process buffer
> > > pointers being passed by Jack to Muse, saying to myself "whaaa?"
> > > They seemed wrong, but what could I do? Other apps did it too...)
> >
> > Hugh...., this seems weird. Again seeing the Muse JACK code would
> > help...
>
> If I may be very specific, if it helps...
> With Jack '1', all of a sudden there will be distortion in audio output.
> My tests seemed to indicate that Jack was giving the app the wrong
>  port playback buffer pointers. The app would 'dutifully' fill each buffer,
>  but what came out of Jack was badly distorted sound - the wrong data.
> By selecting a very long Jack buffer period of 4096 and a low
>  sample rate, I was able to hear that each data buffer being played
>  was in fact partially correct, but the last (or first) small portion of
> the buffer was not correct, hence with a short buffer size it sounds really
> bad. I verified the data blocks filling the buffers were correct and
> CONTIGUOUS (no gaps) !
>
> Any thoughts on what's going on there?
> I am sure I've heard other apps do it too, but It's been a while since
>  I tried them. I have two different sound cards and it does it on both.
> With Jack '2' everything is fine so far. Nothing else changed...
>
> Tim.
> _______________________________________________
> Jack-Devel mailing list
> Jack-Devel@...
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

Hi, the SVN wouldn't build last night but did tonight.
Here's the output, after removing the scheduling code
 and committing the change to the Muse CVS tree.
(The branch is Muse CVS REL07). Thanks. Tim.

Start euid: 500 ruid: 500, Now euid 500
initJackAudio()
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_MusE-1
Jack: Already connected name = MusE-1
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = MusE-1 refnum = 3
initJackAudio(): client MusE-1 opened.
initJackAudio(): registering client...
Jack: jack_set_graph_order_callback ext_client 83a1a28 client 83a1a28
Jack: SetGraphOrderCallback
global lib:       </usr/local/lib/muse>
global share:     </usr/local/share/muse>
muse home:        </home/col>
project dir:      <./>
user instruments: </home/col/muse_instruments>
scan ladspa plugin dir </usr/local/lib/muse/plugins>
scan ladspa plugin dir </usr/lib/ladspa/>
RemoteVSTClient: all cache files are up-to-date, not running scanner
scan ladspa plugin dir </home/col/.ladspa>
scan ladspa plugin dir </usr/local/lib/ladspa>
QtLibraryPath:
  </usr/local/lib/muse/qtplugins>
  </usr/lib/qt3/plugins>
  </usr/lib/kde3/plugins/>
  </home/col/.kde/lib/kde3/plugins/>
  </usr/lib/qt3/plugins/lib>
  </usr/local/bin>
load user instrument definitions from </home/col/muse_instruments>
load instrument definitions from </usr/local/share/muse/instruments>
READ IDF /usr/local/share/muse/instruments/Roland-XP30.idf
READ IDF /usr/local/share/muse/instruments/Roland_FantomXR.idf
READ IDF /usr/local/share/muse/instruments/Roland-SCD70.idf
READ IDF /usr/local/share/muse/instruments/Korg-X50.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif-Rack.idf
READ IDF /usr/local/share/muse/instruments/emuproteus2000.idf
READ IDF /usr/local/share/muse/instruments/Access_Virus.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR530.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif.idf
READ IDF /usr/local/share/muse/instruments/Alesis-QS-78R.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-S90.idf
READ IDF /usr/local/share/muse/instruments/AlesisQS6.idf
READ IDF /usr/local/share/muse/instruments/ns5r.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR275.idf
READ IDF /usr/local/share/muse/instruments/xg.idf
READ IDF /usr/local/share/muse/instruments/MC505.idf
READ IDF /usr/local/share/muse/instruments/Korg-MS2000R.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-microQ.idf
READ IDF /usr/local/share/muse/instruments/MC303.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-Q.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-09.idf
READ IDF /usr/local/share/muse/instruments/Emu-4mbgsgmmt-sf.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetA.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetB.idf
READ IDF /usr/local/share/muse/instruments/Roland-E28.idf
READ IDF /usr/local/share/muse/instruments/Akai-SG01v.idf
READ IDF /usr/local/share/muse/instruments/gs.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-01v.idf
READ IDF /usr/local/share/muse/instruments/gm.idf
READ IDF /usr/local/share/muse/instruments/Waldorf_Microwave-I.idf
READ IDF /usr/local/share/muse/instruments/Hammond_XB-1.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-02.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P50m.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P100.idf
READ IDF /usr/local/share/muse/instruments/ZynAdd-1_4.idf
initMidiAlsa
ALSA port add: <Midi Through Port-0>, 14:0 flags 3 0x63
ALSA port add: <EMU10K1 MPU-401 (UART)>, 16:0 flags 3 0x7f
ALSA port add: <Emu10k1 Port 0>, 17:0 flags 1 0x42
ALSA port add: <Emu10k1 Port 1>, 17:1 flags 1 0x42
ALSA port add: <Emu10k1 Port 2>, 17:2 flags 1 0x42
ALSA port add: <Emu10k1 Port 3>, 17:3 flags 1 0x42
ALSA port add: <M Audio Delta 1010LT MIDI>, 20:0 flags 3 0x7f
ALSA port add: <qjackctl>, 128:0 flags 1 0xc2
Start thread Midi with priority 80
Trying RTC timer...
got timer = 55
Start thread Disc with priority 0
searching for software synthesizer in </usr/local/lib/muse/synthi>
7 soft synth found
starting with default template
Jack: JackClient::PortRegister ref = 3 name = MusE-1:Out 1-0 type = 32 bit
  float mono audio port_index = 23
Jack: JackClient::PortRegister ref = 3 name = MusE-1:Out 1-1 type = 32 bit
  float mono audio port_index = 24
Thread <Disc> set to SCHED_OTHER priority 0
watchdog set to SCHED_FIFO priority 99
Thread <Midi> set to SCHED_FIFO priority 80
Jack: JackClient::Activate
Jack: JackClient::StartThread : period = 2666 computation = 0 constraint =
  2666
Jack: Create non RT thread
Jack: ThreadHandler: start
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kActivateClient name = MusE-1 ref = 3
jack calling when audio is disconnected!
... repeated 7 more times
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
... repeated 13 more times
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
jack calling when audio is disconnected!
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
jack calling when audio is disconnected!
... repeated 11 more times
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
jack calling when audio is disconnected!
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
jack calling when audio is disconnected!
... repeated 14 more times
Jack: JackClient::Connect src = MusE-1:Out 1-0 dst = system:playback_1
jack calling when audio is disconnected!
... repeated 12 more times
Jack: JackClient::kGraphOrderCallback
jack calling when audio is disconnected!
JACK: graph changed
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::Connect src = MusE-1:Out 1-1 dst = system:playback_2
jack calling when audio is disconnected!
... repeated 6 more times
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.500_default_MusE-1 usec =
  2147483647 err = Interrupted system call
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
JACK ERROR: JackActivationCount::Signal value = 0 ref = 3
Jack: TransportLocate pos = 0
Jack: RequestNewPos pos = 0
lash_open_socket: could not connect to host 'localhost', service '14541'
lash_comm_connect_to_server: could not create server connection
Jack: JackClient::AddClient name = LASH_Server, ref = 4
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_LASH_Server
Jack: JackClient::kAddClient fName = MusE-1 name = LASH_Server
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_LASH_Server
Jack: Already connected name = LASH_Server
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = LASH_Server refnum = 4
Connected to JACK server with client name 'LASH_Server'
Jack: jack_set_graph_order_callback ext_client 80658c8 client 80658c8
Jack: SetGraphOrderCallback
Jack: JackClient::Activate
Jack: JackClient::kActivateClient name = LASH_Server ref = 4
Opened ALSA sequencer with client ID 130
Listening for connections
Created project project-53 in directory /home/col/audio-projects/project-53
Added client e65532a2-a021-46a2-a63a-68d25dde0420 of class MusE to project
project-53

Muse is now running at this point with audio and MIDI, but still no cursor
 location functionality.


On Monday 15 June 2009 04:30:40 you wrote:

> Le 14 juin 09 à 23:53, Tim a écrit :
> > Hello, I've been so busy fixing Muse I am just now getting around
> > to trying Muse with Jack 2. I thought I would ask here before
> > attempting to fool around with the problems we're having...
> >
> > We get errors like this:
> > JACK ERROR: JackActivationCount::Signal value = 0 ref = 4
>
> This usually happens when the application audio cycle cannot complete
> in time (for whatever reason). Do you have a more complete log file to
> show?
>
> Starting the server in verbose mode (- v ) can help understand what
> happens.
>
> Where is the source code of Muse JACK module?
>
> > Also, probably because of that error, we cannot move the Muse cursor,
> > which calls jack_transport_locate().
> > After jack_transport_locate() is called, I see that the sync callback
> > is NOT called.
> > I verified that with Jack 0.116.2, after jack_transport_locate() is
> > called,
> > the sync callback is in fact called.
> >
> > I have replaced jack_client_new() with jack_client_open(), albeit
> > without any options.
> >
> > Gotta be something simple... Can anyone help?
> > Thanks. Tim.
>
> A bug in transport has been fixed in SVN. Can you possibly test the
> SVN version and report?
>
> See : http://jackaudio.org/download
>
> Thanks.
>
> Stephane

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

>
> Anyways, about that error shown above:
> "Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.
> 500_default_MusE-1 usec =
>          2147483647 err = Interrupted system call "
> This shows up many times, not just the one time shown, but only during
> startup. After Muse is running, when locating, they don't show up.
> Could this error be the culprit?


There is indeed an issue with this "Interrupted system call " error.  
I've just corrected JackFifo::TimedWait for that (SVN r3560). Can you  
please test latest JACK2 SVN and report?

Then we can work on the transport issue later on.

Thanks.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Tim-442]

Hi, I tried with today's Jack SVN and the Timed Wait error is gone now.
Alas, still no locating functionality.
Output, and observations afterwards:

Start euid: 500 ruid: 500, Now euid 500
initJackAudio()
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_MusE-1
Jack: Already connected name = MusE-1
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = MusE-1 refnum = 3
initJackAudio(): client MusE-1 opened.
initJackAudio(): registering client...
Jack: jack_set_graph_order_callback ext_client 83a1a28 client 83a1a28
Jack: SetGraphOrderCallback
global lib:       </usr/local/lib/muse>
global share:     </usr/local/share/muse>
muse home:        </home/col>
project dir:      <./>
user instruments: </home/col/muse_instruments>
scan ladspa plugin dir </usr/local/lib/muse/plugins>
scan ladspa plugin dir </usr/lib/ladspa/>
RemoteVSTClient: all cache files are up-to-date, not running scanner
scan ladspa plugin dir </home/col/.ladspa>
scan ladspa plugin dir </usr/local/lib/ladspa>
QtLibraryPath:
  </usr/local/lib/muse/qtplugins>
  </usr/lib/qt3/plugins>
  </usr/lib/kde3/plugins/>
  </home/col/.kde/lib/kde3/plugins/>
  </usr/lib/qt3/plugins/lib>
  </home/col/Source/muse-20090201-CVS-REL07-fresh/muse>
load user instrument definitions from </home/col/muse_instruments>
load instrument definitions from </usr/local/share/muse/instruments>
READ IDF /usr/local/share/muse/instruments/Roland-XP30.idf
READ IDF /usr/local/share/muse/instruments/Roland_FantomXR.idf
READ IDF /usr/local/share/muse/instruments/Roland-SCD70.idf
READ IDF /usr/local/share/muse/instruments/Korg-X50.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif-Rack.idf
READ IDF /usr/local/share/muse/instruments/emuproteus2000.idf
READ IDF /usr/local/share/muse/instruments/Access_Virus.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR530.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-Motif.idf
READ IDF /usr/local/share/muse/instruments/Alesis-QS-78R.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-S90.idf
READ IDF /usr/local/share/muse/instruments/AlesisQS6.idf
READ IDF /usr/local/share/muse/instruments/ns5r.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-PSR275.idf
READ IDF /usr/local/share/muse/instruments/xg.idf
READ IDF /usr/local/share/muse/instruments/MC505.idf
READ IDF /usr/local/share/muse/instruments/Korg-MS2000R.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-microQ.idf
READ IDF /usr/local/share/muse/instruments/MC303.idf
READ IDF /usr/local/share/muse/instruments/Waldorf-Q.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-09.idf
READ IDF /usr/local/share/muse/instruments/Emu-4mbgsgmmt-sf.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetA.idf
READ IDF /usr/local/share/muse/instruments/Korg-X5DR-PresetB.idf
READ IDF /usr/local/share/muse/instruments/Roland-E28.idf
READ IDF /usr/local/share/muse/instruments/Akai-SG01v.idf
READ IDF /usr/local/share/muse/instruments/gs.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-01v.idf
READ IDF /usr/local/share/muse/instruments/gm.idf
READ IDF /usr/local/share/muse/instruments/Waldorf_Microwave-I.idf
READ IDF /usr/local/share/muse/instruments/Hammond_XB-1.idf
READ IDF /usr/local/share/muse/instruments/Roland_SRX-02.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P50m.idf
READ IDF /usr/local/share/muse/instruments/Yamaha-P100.idf
READ IDF /usr/local/share/muse/instruments/ZynAdd-1_4.idf
initMidiAlsa
ALSA port add: <Midi Through Port-0>, 14:0 flags 3 0x63
ALSA port add: <EMU10K1 MPU-401 (UART)>, 16:0 flags 3 0x7f
ALSA port add: <Emu10k1 Port 0>, 17:0 flags 1 0x42
ALSA port add: <Emu10k1 Port 1>, 17:1 flags 1 0x42
ALSA port add: <Emu10k1 Port 2>, 17:2 flags 1 0x42
ALSA port add: <Emu10k1 Port 3>, 17:3 flags 1 0x42
ALSA port add: <M Audio Delta 1010LT MIDI>, 20:0 flags 3 0x7f
ALSA port add: <qjackctl>, 128:0 flags 1 0xc2
Start thread Midi with priority 80
Trying RTC timer...
got timer = 55
Start thread Disc with priority 0
searching for software synthesizer in </usr/local/lib/muse/synthi>
7 soft synth found
starting with default template
Jack: JackClient::PortRegister ref = 3 name = MusE-1:Out 1-0 type = 32 bit
  float mono audio port_index = 23
Jack: JackClient::PortRegister ref = 3 name = MusE-1:Out 1-1 type = 32 bit
  float mono audio port_index = 24
watchdog set to SCHED_FIFO priority 99
Thread <Disc> set to SCHED_OTHER priority 0
Jack: JackClient::Activate
Jack: JackClient::StartThread : period = 2666 computation = 0 constraint =  
  2666
Jack: Create non RT thread
Jack: ThreadHandler: start
Jack: JackClient::kActivateClient name = MusE-1 ref = 3
jack calling when audio is disconnected!
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
jack calling when audio is disconnected!
Thread <Midi> set to SCHED_FIFO priority 80
Jack: JackClient::Connect src = MusE-1:Out 1-0 dst = system:playback_1
jack calling when audio is disconnected!
...repeated 27 more times
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
...repeated 7 more times
Jack: JackClient::Connect src = MusE-1:Out 1-1 dst = system:playback_2
jack calling when audio is disconnected!
...repeated 26 more times
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
jack calling when audio is disconnected!
Jack: TransportLocate pos = 0
Jack: RequestNewPos pos = 0
lash_open_socket: could not connect to host 'localhost', service '14541'
lash_comm_connect_to_server: could not create server connection
Jack: JackClient::AddClient name = LASH_Server, ref = 4
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_LASH_Server
Jack: JackClient::kAddClient fName = MusE-1 name = LASH_Server
Jack: JackClient::kGraphOrderCallback
JACK: graph changed
Jack: JackClient::SetupDriverSync driver sem in flush mode
Jack: JackFifo::ConnectAux name = /dev/shm/jack_fifo.500_default_LASH_Server
Jack: Already connected name = LASH_Server
Jack: Clock source : system clock via clock_gettime
Jack: JackLibClient::Open name = LASH_Server refnum = 4
Connected to JACK server with client name 'LASH_Server'
Jack: jack_set_graph_order_callback ext_client 80658c8 client 80658c8
Jack: SetGraphOrderCallback
Jack: JackClient::Activate
Jack: JackClient::kActivateClient name = LASH_Server ref = 4
Opened ALSA sequencer with client ID 130
Listening for connections
Created project project-53 in directory /home/col/audio-projects/project-53
Added client ef9bbffd-4024-49e8-9d59-255d80ea383e of class MusE to project
  project-53
...
At this point Muse is running...

Here, I am trying to move the location cursor:
Jack: TransportLocate pos = 288000
Jack: RequestNewPos pos = 288000
Jack: TransportLocate pos = 672000
Jack: RequestNewPos pos = 672000
Jack: TransportLocate pos = 960000
Jack: RequestNewPos pos = 960000
...
The transport time code in QJackctl is changing,
 but nothing is happening in Muse.
I observed Muse's Jack sync callback is definitely NOT
 being called during these times.
I verified that whenever the sync callback IS in fact called,
 it is returning 'true' when it is ready to roll...

Muse will go into play mode Ok. The cursor moves by itself.
I observed when starting play mode, the sync callback IS being called.

I appreciate the help, I know you are quite busy.
Thanks. Tim.


On Tuesday 16 June 2009 04:18:35 you wrote:

> > Anyways, about that error shown above:
> > "Jack: JackFifo::TimedWait name = /dev/shm/jack_fifo.
> > 500_default_MusE-1 usec =
> >          2147483647 err = Interrupted system call "
> > This shows up many times, not just the one time shown, but only during
> > startup. After Muse is running, when locating, they don't show up.
> > Could this error be the culprit?
>
> There is indeed an issue with this "Interrupted system call " error.
> I've just corrected JackFifo::TimedWait for that (SVN r3560). Can you
> please test latest JACK2 SVN and report?
>
> Then we can work on the transport issue later on.
>
> Thanks.
>
> Stephane

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

I finally succedeed in compiling Muse. Then transport seems to be  
working here:

- with an empty score,  "start" ==> processSync callback is called but  
since the sequence is empty the "stopTransport" method is called just  
after and transport never starts

- if LOOP is activated, start" ==> processSync callback is called and  
transport works as expected.

So i don't see specific problems related to JACK2 here.

If more problems stay, then checking again the Muse transport  
implementation should be done.

Stephane
 
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 19 juin 09 à 00:55, Tim a écrit :

> If you can try moving the cursor around (the red bar),
> it is supposed to move (whether the song is empty or not).
> Also the FF/REW buttons don't work.
>
> Those are the two things that are not working,
> but they work Ok with Jack-1.
> Thanks. Tim.
>

Ok, it was a bug in JACK2 transport engine. Fixed in SVN rev 3562.

Thanks for reporting.

Stephane
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org