Re: [Jack-Devel] jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"

[..]

>> long story short: it was not in synchronous mode when the errors 
>> happened and I can reproduce the JackActivationCount by + running
>> in async mode + using lots of DSP-load
> 
> Ok, this makes much more sense!
> 
>> 
>> But why are these messages printed out by default? Shouldn't
>> signaling an x-run be enough?
> 
> They are still not "strict XRun": in asynchronous mode XRuns are
> detected by the server which just checks that all clients have be run
> previous cycle. It then print something like:
> 
> "JackEngine::XRun : client = XXX was not run: state = 2"
> 
> Don't you see there kind of messages along the
> "JackActivationCount...." ones?

yes.

jackd verbose log:
 JackEngine::XRun: client = ardour was not run: state = 2
 JackAudioDriver::ProcessGraphAsyncMaster: Process error
 JackEngine::XRun: client = ardour was not run: state = 2
 JackAudioDriver::ProcessGraphAsyncMaster: Process error

ardour log:
 [ERROR]: JACK: JackActivationCount::Signal value = 0 ref = 3
 [ERROR]: JACK: JackActivationCount::Signal value = 0 ref = 3


>> IMHO these msgs should only be generated in verbose mode, because
>> printing those messages just makes things worse: more system load
>> due to logging, etc. -> even more messages.
> 
> OK this can be done quite easily...

Good!

This is only really relevant when DSP load is ~ 85-95%.



>>[..]
> Yes -S for "synchronous" is a server setting. It can actually be used
> with different kind of backend.

Well, I do launch jackdbus and then call
    jack_control eps sync true
_before_ starting the engine. There's no "-S" parameter involved.

robin

1310742395.5903_0.ltw:2,a <4E20575C.4060100 at gareus dot org>