Jack2 xrun messages

[Patrick Shirkey]

Hi,

With jack2 what's the difference between a jackEngine xrun and an alsa xrun?

Does the latter cause a dropout and the former just require extra cpu to
catch things up?



Cheers.

--

Patrick Shirkey
Boost Hardware Ltd

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Stéphane Letz]

Le 3 sept. 09 à 14:45, Patrick Shirkey a écrit :

> Hi,
>
> With jack2 what's the difference between a jackEngine xrun and an  
> alsa xrun?
>
> Does the latter cause a dropout and the former just require extra  
> cpu to catch things up?
>
>
>
> Cheers.
>
> --
>
> Patrick Shirkey
> Boost Hardware Ltd
>

By default JACK2 runs in so called "asynchronous" mode. In this mode  
at each cycle, the engine read the input buffers, write the output  
buffers from the *previous* cycle and activate the graph, but *does  
not wait* for end of graph computation. (In synchronous mode on the  
contrary, JACK server does: read input, activate, wait for graph end,  
write output.)

In asynchronous mode, the server checks at each cycle that all the  
clients have correctly run the previous cycle: this is supposed to be  
the case since the server is regularly activated by the audio card. If  
a client has not run, then an " jackEngine xrun" is issued.  And the  
ALSA backend itself may issue xrun, thus the 2 kinds of xrun.

If you run JACK in synchronous make (-S) then late clients will cause  
the server callback to be delayed (since the server is waiting for  
graph end) and a late will probably cause an complete ALSA xrun.

Stéphane




_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jonathan Ryshpan]

On Thu, 2009-09-03 at 15:07 +0200, Stéphane Letz wrote:

> Le 3 sept. 09 à 14:45, Patrick Shirkey a écrit :
>
> > Hi,
> >
> > With jack2 what's the difference between a jackEngine xrun and an  
> > alsa xrun?
> >
> > Does the latter cause a dropout and the former just require extra  
> > cpu to catch things up?
> >
> By default JACK2 runs in so called "asynchronous" mode. In this mode  
> at each cycle, the engine read the input buffers, write the output  
> buffers from the *previous* cycle and activate the graph, but *does  
> not wait* for end of graph computation. (In synchronous mode on the  
> contrary, JACK server does: read input, activate, wait for graph end,  
> write output.)
>
> In asynchronous mode, the server checks at each cycle that all the  
> clients have correctly run the previous cycle: this is supposed to be  
> the case since the server is regularly activated by the audio card. If  
> a client has not run, then an " jackEngine xrun" is issued.  And the  
> ALSA backend itself may issue xrun, thus the 2 kinds of xrun.
>
> If you run JACK in synchronous make (-S) then late clients will cause  
> the server callback to be delayed (since the server is waiting for  
> graph end) and a late will probably cause an complete ALSA xrun.

I surmise that when JACK2 is started by qjackctl the alsa xruns show up
in parentheses and the jackengine xruns show up to their left.  So an
indication
        4(3) in red
would indicate 4 jackengine xruns and 3 alsa xruns.  Is this correct?

BTW: I don't see any way to invoke jackd in synchronous mode using
qjackctl.  Am I missing something?

Thanks - jon


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Rui Nuno Capela]

On Thu, September 3, 2009 17:07, Jonathan Ryshpan wrote:

> On Thu, 2009-09-03 at 15:07 +0200, Stéphane Letz wrote:
>
>> Le 3 sept. 09 à 14:45, Patrick Shirkey a écrit :
>>
>>
>>> Hi,
>>>
>>>
>>> With jack2 what's the difference between a jackEngine xrun and an
>>> alsa xrun?
>>>
>>> Does the latter cause a dropout and the former just require extra
>>> cpu to catch things up?
>>>
>> By default JACK2 runs in so called "asynchronous" mode. In this mode
>> at each cycle, the engine read the input buffers, write the output
>> buffers from the *previous* cycle and activate the graph, but *does not
>> wait* for end of graph computation. (In synchronous mode on the
>> contrary, JACK server does: read input, activate, wait for graph end,
>> write output.)
>>
>> In asynchronous mode, the server checks at each cycle that all the
>> clients have correctly run the previous cycle: this is supposed to be the
>> case since the server is regularly activated by the audio card. If a
>> client has not run, then an " jackEngine xrun" is issued.  And the ALSA
>> backend itself may issue xrun, thus the 2 kinds of xrun.
>>
>> If you run JACK in synchronous make (-S) then late clients will cause
>> the server callback to be delayed (since the server is waiting for graph
>> end) and a late will probably cause an complete ALSA xrun.
>
> I surmise that when JACK2 is started by qjackctl the alsa xruns show up
> in parentheses and the jackengine xruns show up to their left.  So an
> indication 4(3) in red
> would indicate 4 jackengine xruns and 3 alsa xruns.  Is this correct?
>

no. quite the contrary.

in parenthesis is the jack engine xrun callback count. to the left is the
xrun count as detected from captured stderr/stdout message stream, usually
saying:

*** alsa_pcm: xrun of at least ...

or something of the sorts.


> BTW: I don't see any way to invoke jackd in synchronous mode using
> qjackctl.  Am I missing something?
>

in settings, edit the server path to "jackd -S" or something

byee
--
rncbc aka Rui Nuno Capela
rncbc@...

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Jonathan Ryshpan]

On Thu, 2009-09-03 at 17:22 +0100, Rui Nuno Capela wrote:
> > BTW: I don't see any way to invoke jackd in synchronous mode using
> > qjackctl.  Am I missing something?
> >
>
> in settings, edit the server path to "jackd -S" or something

Hokey, but effective.

Thanks - jon


_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Dominic Sacré]

Hi Rui,

On Thursday 03 of September 2009 18:22:20 Rui Nuno Capela wrote:
> in parenthesis is the jack engine xrun callback count. to the left is
> the xrun count as detected from captured stderr/stdout message stream

Could you elaborate on what these two numbers mean, in particular what
the difference between them is?

I've seen cases where both numbers differed quite significantly. For
example, just a couple of xruns detected from jack's output, but
thousands or even millions of xrun callbacks (on an admittedly pretty
much broken setup).
I'm wondering what the "real" number of xruns is, and which of these
numbers I should be worried about with regard to audible problems.


Dominic



_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Rui Nuno Capela]

Dominic Sacré wrote:

> Hi Rui,
>
> On Thursday 03 of September 2009 18:22:20 Rui Nuno Capela wrote:
>> in parenthesis is the jack engine xrun callback count. to the left is
>> the xrun count as detected from captured stderr/stdout message stream
>
> Could you elaborate on what these two numbers mean, in particular what
> the difference between them is?
>
> I've seen cases where both numbers differed quite significantly. For
> example, just a couple of xruns detected from jack's output, but
> thousands or even millions of xrun callbacks (on an admittedly pretty
> much broken setup).
> I'm wondering what the "real" number of xruns is, and which of these
> numbers I should be worried about with regard to audible problems.
>

take aim to the number inside the parenthesis. ie. the xrun callback
count as reported to jack clients. it is the one, no doubt, is telling
you the truth from jack horse's mouth.

the other number, the one on the left, is probably there only for
historical reasons, pure legacy crap reminiscent from qjackctl
primordial ages, when there was no other way to detect an xrun but
getting down to its knees and parse the stdout/stderr stream from jackd :)

byee
--
rncbc aka Rui Nuno Capela
rncbc@...
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Ralf Mardorf]

Rui Nuno Capela wrote:

> Dominic Sacré wrote:
>  
>> Hi Rui,
>>
>> On Thursday 03 of September 2009 18:22:20 Rui Nuno Capela wrote:
>>    
>>> in parenthesis is the jack engine xrun callback count. to the left is
>>> the xrun count as detected from captured stderr/stdout message stream
>>>      
>> Could you elaborate on what these two numbers mean, in particular what
>> the difference between them is?
>>
>> I've seen cases where both numbers differed quite significantly. For
>> example, just a couple of xruns detected from jack's output, but
>> thousands or even millions of xrun callbacks (on an admittedly pretty
>> much broken setup).
>> I'm wondering what the "real" number of xruns is, and

>> which of these
>> numbers I should be worried about with regard to audible problems.
>>    

What you hear is audible ;).

Some days ago I used bad settings and had audible problems even when
there were no xruns, in the past I sometimes had xruns, but no audible
problems. I guess our ears are still the best method to find out what's
audible and what not.

> take aim to the number inside the parenthesis. ie. the xrun callback
> count as reported to jack clients. it is the one, no doubt, is telling
> you the truth from jack horse's mouth.
>
> the other number, the one on the left, is probably there only for
> historical reasons, pure legacy crap reminiscent from qjackctl
> primordial ages, when there was no other way to detect an xrun but
> getting down to its knees and parse the stdout/stderr stream from jackd :)
>
> byee
>  

--
Secret of Tux: http://images.wallaceandgromit.com/user_uploads/forum_thumbnails/5/75/355.jpg
"Gromit bit me" says HMV dog: http://img.dailymail.co.uk/i/pix/2007/03_03/GomitHMVPA_468x319.jpg

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Dominic Sacré]

On Thursday 03 of September 2009 21:11:35 Rui Nuno Capela wrote:

> > Could you elaborate on what these two numbers mean, in particular
> > what the difference between them is?
>
> take aim to the number inside the parenthesis. ie. the xrun callback
> count as reported to jack clients. it is the one, no doubt, is
> telling you the truth from jack horse's mouth.
>
> the other number, the one on the left, is probably there only for
> historical reasons, pure legacy crap reminiscent from qjackctl
> primordial ages, when there was no other way to detect an xrun but
> getting down to its knees and parse the stdout/stderr stream from
> jackd :)

Thanks a lot for the explanation. From your description is sounds like
the first number is pretty much redundant, so maybe it would be a good
idea to avoid confusion in the future and simply remove it?
_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

[Rui Nuno Capela]

On Fri, September 4, 2009 01:09, Dominic Sacré wrote:

> On Thursday 03 of September 2009 21:11:35 Rui Nuno Capela wrote:
>
>>> Could you elaborate on what these two numbers mean, in particular
>>> what the difference between them is?
>>
>> take aim to the number inside the parenthesis. ie. the xrun callback
>> count as reported to jack clients. it is the one, no doubt, is telling
>> you the truth from jack horse's mouth.
>>
>> the other number, the one on the left, is probably there only for
>> historical reasons, pure legacy crap reminiscent from qjackctl
>> primordial ages, when there was no other way to detect an xrun but
>> getting down to its knees and parse the stdout/stderr stream from jackd
>> :)
>>
>
> Thanks a lot for the explanation. From your description is sounds like
> the first number is pretty much redundant, so maybe it would be a good
> idea to avoid confusion in the future and simply remove it?
>

given that it detects occurrences on the jackd output stream through a
user configurable regex, you can use it to some other stats besides xruns
in particular...

so legacu crap stays put.

anyway, i guess, qjackctl as you know it, may be legacy crap altogether,
now that the ladi tools are emerging out of the blur ;)

cheers
--
rncbc aka Rui Nuno Capela
rncbc@...

_______________________________________________
Jack-Devel mailing list
Jack-Devel@...
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org