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

PrevNext  Index
DateFri, 15 Jul 2011 23:58:15 +0200
From Robin Gareus <[hidden] at gareus dot org>
ToStéphane Letz <[hidden] at grame dot fr>
CcJack devel <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"
Follow-UpStéphane Letz Re: [Jack-Devel] jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"
Follow-UpNedko Arnaudov Re: [Jack-Devel] jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"
On 07/15/2011 06:38 PM, Stéphane Letz wrote:
[..]

> But basically you are going to get *real* XRun error message in this
> case right?

Yes. (BTW. Could one disable those as well? Does jack have a "quiet"
mode that only logs fatal errors?)

>> This is only really relevant when DSP load is ~ 85-95%.
> 
> So I can make "JackActivationCount" report in verbose mode only, but
> we agree that there still will be  XRun error message  right?

Yes; usually those x-runs are just a transient condition.

AFAIK, logging of Xruns by jackdbus is done in the non-RT thread which
does not add to DSP load.

One could view this change as a workaround for apps that catch and print
"JackActivationCount" messages (I guess even from the RT thread). Known
susceptible apps are pure-data and ardour2/3 and there are possibly a
few more.

It makes me wonder: Why are the Xrun messages exclusively in jack.log
and the "JackActivationCount" messages exclusively in the application
log? Here the latter do not show up in jack.log.


Thanks,
robin
PrevNext  Index

1310767123.21679_0.ltw:2,a <4E20B7F7.3090403 at gareus dot org>