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

On 07/16/2011 07:29 AM, Stéphane Letz wrote:
> 
> Le 15 juil. 2011 à 23:58, Robin Gareus a écrit :
> 
>> 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?)
>> 
> 
> Jack2 has 3 kinds of messages printed by :
> 
> - jack_error (real important ones..)
> 
> - jack_info : informative purpose
> 
> - jack_log: for debugging purposes...
> 
> 
> BTW, how does jack1 displays XRun ? (or any  fatal errors)

I don't know the details.  But I remember early versions of qjackctl
parsing jackd's stdout to capture x-runs via regexp (This option is
still available in current release of qjackctl). So I suppose everything
goes to stdout/stderr.

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

Maybe what all that those apps have in common is that they're using
'jack_error_callback()'. So the jack-errors do not end up in jackd's log
any more but are handled by the application.

jack2 does no queue those messages but passes them directly to the
configured log-callback:

  jack_error() | jack_info() -> jack_format_and_log()
  -> log_function() -> jack_error_callback() | jack_info_callback()

so if jack_error() is called from real-time context (e.g.
JackActivationCount), also the jack_log_callback() of the
client-application is invoked with realtime privileges! At least with
the current jackdmp implementation.

>> Thanks, robin
> 
> 
> This is in jackdbus right?

indeed.

> How the info/log/error message are handled can be configurated with
> the jack_set_error_function/jack_set_info_function from jack.h API.
> You should look in how jackdbus configure them. And/or ask Nedko...

dbus/jackdbus.c does not expose them, but hardcodes internal handlers
that simply append the messages to the log-file.

Oh well,
robin

1310820702.21059_0.ltw:2,a <4E218945.5030204 at gareus dot org>