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

PrevNext  Index
DateSat, 16 Jul 2011 15:09:55 +0200
From Stéphane Letz <[hidden] at grame dot fr>
ToRobin Gareus <[hidden] at gareus dot org>
CcJack devel <[hidden] at lists dot jackaudio dot org>
In-Reply-ToRobin Gareus [Jack-Devel] jackd-logging -- was jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"
Follow-UpRobin Gareus Re: [Jack-Devel] jackd-logging -- was jackd2+ardour3 - tracking down "JackActivationCount::Signal value = 0 ref = INT"
Le 16 juil. 2011 à 14:51, Robin Gareus a écrit :

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

Same for jack2.

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

I'm a bit lost here.  

RT threads are supposed to call "set_threaded_log_function" so that "JackMessageBufferAdd" is used for logging, thus no blocking logging functions are used in RT context. Otherwise non RT versions are used.

What is the exact problem? (beside the JackActivationCount be printed by "jack_error" and should be moved to "jack_log")



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

Ask Nedko !!

Stéphane 
PrevNext  Index

1310821798.23204_0.ltw:2,a <67E25736-9862-4E97-98BF-1922548127BF at grame dot fr>