Re: Muse and JackActivationCount errors, also my COMPLIMENTS to the devels ...

> 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
>