|
»
« Return to Thread: Muse and JackActivationCount errors
Re: Muse and JackActivationCount errors
by Tim-442
::
Rate this Message:
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
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
« Return to Thread: Muse and JackActivationCount errors
| Free embeddable forum powered by Nabble | Forum Help |
