jmess vs. jack 1.9.6, lots of connections

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
I have run into a most puzzling problem. It is a long story but the end
result could be summarized as:

- start jack (1.9.6)
- start a bunch of jack clients with many ports (sooperlooper,
supercollider, 4 x zita-rev1...)
- run jmess to disconnect everything first and then connect ports listed
in an xml file

If you run jmess jackd is left in a weird state, it keeps printing:

----

JackEngine::XRun: client = SuperCollider was not run: state = 2

JackAudioDriver::ProcessAsync Process error

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackEngine::XRun: client = SuperCollider was not run: state = 2

JackAudioDriver::ProcessAsync Process error

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

----

That keeps going forever (AFAICT). Apparently the only client affected
is SuperCollider (which is the one generating the most system load). I
just tried not including SuperCollider (ie: running jmess without SC
started) and I get no errors.

But it gets weirder.

If I switch the cpu speed governor to "Performance" mode (from "On
Demand") then the messages stop. Or if I change the governor and then do
all the connections with jmess then I get some messages but they stop.
But jackd is now very touchy and pretty much anything I do on the
computer generates messages like this one:

----

19:25:42.934 XRUN callback (385).

JackEngine::XRun: client = SuperCollider was not run: state = 2

JackAudioDriver::ProcessAsync Process error

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

JackPosixMutex::Unlock res = 1

----

If I disconnect all ports the messages dissapear (?)

If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed
stop) then the messages dissapear forever and everything seems to work
fine after that (???). Starting the cpuspeed daemon makes the messages
return.

I hacked the jmess code and made sure it is doing what jack_connect is
doing and the problem still happens. I then added a delay between
connection calls and everything is fine for a while, while jmess is
making the connections (ie: I don't get messages) but at some point the
messages start appearing and that's it.

Time for dinner.....

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/09/2010 07:51 PM, Fernando Lopez-Lezcano wrote:

> If I disconnect all ports the messages dissapear (?)
>
> If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed
> stop) then the messages dissapear forever and everything seems to work
> fine after that (???). Starting the cpuspeed daemon makes the messages
> return.
>
> I hacked the jmess code and made sure it is doing what jack_connect is
> doing and the problem still happens. I then added a delay between
> connection calls and everything is fine for a while, while jmess is
> making the connections (ie: I don't get messages) but at some point the
> messages start appearing and that's it.
>
> Time for dinner.....

Just in case, "jackd -S" does not make any difference.

It appears that the problem starts with 95 connections (or rather 96)...
changing the time waiting between connections does not seem to affect
that value.

-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Hermann Meyer
Am Donnerstag, den 09.12.2010, 20:50 -0800 schrieb Fernando
Lopez-Lezcano:

> On 12/09/2010 07:51 PM, Fernando Lopez-Lezcano wrote:
> > If I disconnect all ports the messages dissapear (?)
> >
> > If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed
> > stop) then the messages dissapear forever and everything seems to work
> > fine after that (???). Starting the cpuspeed daemon makes the messages
> > return.
> >
> > I hacked the jmess code and made sure it is doing what jack_connect is
> > doing and the problem still happens. I then added a delay between
> > connection calls and everything is fine for a while, while jmess is
> > making the connections (ie: I don't get messages) but at some point the
> > messages start appearing and that's it.
> >
> > Time for dinner.....
>
> Just in case, "jackd -S" does not make any difference.
>
> It appears that the problem starts with 95 connections (or rather 96)...
> changing the time waiting between connections does not seem to affect
> that value.
>
> -- Fernando

When I work on a port widget I experience that a usleep(10) between many
jack_get_ports call() prevent me for Xrun's with jack2, don't know if it
is related to this ?

greats  hermann


_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Stéphane Letz
In reply to this post by Fernando Lopez-Lezcano

Le 10 déc. 2010 à 04:51, Fernando Lopez-Lezcano a écrit :

> I have run into a most puzzling problem. It is a long story but the end result could be summarized as:
>
> - start jack (1.9.6)
> - start a bunch of jack clients with many ports (sooperlooper, supercollider, 4 x zita-rev1...)
> - run jmess to disconnect everything first and then connect ports listed in an xml file
>
> If you run jmess jackd is left in a weird state, it keeps printing:
>
> ----
>
> JackEngine::XRun: client = SuperCollider was not run: state = 2
>
> JackAudioDriver::ProcessAsync Process error
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackEngine::XRun: client = SuperCollider was not run: state = 2
>
> JackAudioDriver::ProcessAsync Process error
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> ----
>
> That keeps going forever (AFAICT). Apparently the only client affected is SuperCollider (which is the one generating the most system load). I just tried not including SuperCollider (ie: running jmess without SC started) and I get no errors.
>
> But it gets weirder.
>
> If I switch the cpu speed governor to "Performance" mode (from "On Demand") then the messages stop. Or if I change the governor and then do all the connections with jmess then I get some messages but they stop. But jackd is now very touchy and pretty much anything I do on the computer generates messages like this one:
>
> ----
>
> 19:25:42.934 XRUN callback (385).
>
> JackEngine::XRun: client = SuperCollider was not run: state = 2
>
> JackAudioDriver::ProcessAsync Process error
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> JackPosixMutex::Unlock res = 1
>
> ----
>
> If I disconnect all ports the messages dissapear (?)
>
> If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed stop) then the messages dissapear forever and everything seems to work fine after that (???). Starting the cpuspeed daemon makes the messages return.
>
> I hacked the jmess code and made sure it is doing what jack_connect is doing and the problem still happens. I then added a delay between connection calls and everything is fine for a while, while jmess is making the connections (ie: I don't get messages) but at some point the messages start appearing and that's it.
>
> Time for dinner.....
>
> -- Fernando

You don't say what is the Jack DSP CPU value when those XRun start to appear... If your machine is almost fully loaded (in "On Demand" case) then the message could make sense.

Can you check the DSP CPU load?

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Peter Nelson-4
In reply to this post by Fernando Lopez-Lezcano
On Thu, 2010-12-09 at 19:51 -0800, Fernando Lopez-Lezcano wrote:
> I have run into a most puzzling problem. It is a long story but the end
> result could be summarized as:
>
> - start jack (1.9.6)
> - start a bunch of jack clients with many ports (sooperlooper,
> supercollider, 4 x zita-rev1...)
> - run jmess to disconnect everything first and then connect ports listed
> in an xml file


Hi Fernando,

Do you have a multi-core machine? If so then I suspect you are
experiencing jack2's parallelism.

When the ports are not connected, jack2 can process each client in any
order, and in parallel. On a multi-core machine this can use all cores.

Once you've connected the ports together, however, clients must wait for
other clients to finish first, and so some parts cannot be run in
parallel, and thus now there is not enough time to complete everything
within a cycle.

Peter.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Stéphane Letz

Le 10 déc. 2010 à 11:01, Peter Nelson a écrit :

> On Thu, 2010-12-09 at 19:51 -0800, Fernando Lopez-Lezcano wrote:
>> I have run into a most puzzling problem. It is a long story but the end
>> result could be summarized as:
>>
>> - start jack (1.9.6)
>> - start a bunch of jack clients with many ports (sooperlooper,
>> supercollider, 4 x zita-rev1...)
>> - run jmess to disconnect everything first and then connect ports listed
>> in an xml file
>
>
> Hi Fernando,
>
> Do you have a multi-core machine? If so then I suspect you are
> experiencing jack2's parallelism.
>
> When the ports are not connected, jack2 can process each client in any
> order, and in parallel. On a multi-core machine this can use all cores.
>
> Once you've connected the ports together, however, clients must wait for
> other clients to finish first, and so some parts cannot be run in
> parallel, and thus now there is not enough time to complete everything
> within a cycle.
>
> Peter.
> _______________________________________________

Yep... exactly this is why having an info on the consumed CPU would help.

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
In reply to this post by Stéphane Letz
On 12/10/2010 01:38 AM, Stéphane Letz wrote:

>
> Le 10 déc. 2010 à 04:51, Fernando Lopez-Lezcano a écrit :
>
>> I have run into a most puzzling problem. It is a long story but the end result could be summarized as:
>>
>> - start jack (1.9.6)
>> - start a bunch of jack clients with many ports (sooperlooper, supercollider, 4 x zita-rev1...)
>> - run jmess to disconnect everything first and then connect ports listed in an xml file
>>
>> If you run jmess jackd is left in a weird state, it keeps printing:
>>
>> ----
>>
>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>
>> JackAudioDriver::ProcessAsync Process error
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>
>> JackAudioDriver::ProcessAsync Process error
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> ----
>>
>> That keeps going forever (AFAICT). Apparently the only client affected is SuperCollider (which is the one generating the most system load). I just tried not including SuperCollider (ie: running jmess without SC started) and I get no errors.
>>
>> But it gets weirder.
>>
>> If I switch the cpu speed governor to "Performance" mode (from "On Demand") then the messages stop. Or if I change the governor and then do all the connections with jmess then I get some messages but they stop. But jackd is now very touchy and pretty much anything I do on the computer generates messages like this one:
>>
>> ----
>>
>> 19:25:42.934 XRUN callback (385).
>>
>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>
>> JackAudioDriver::ProcessAsync Process error
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> JackPosixMutex::Unlock res = 1
>>
>> ----
>>
>> If I disconnect all ports the messages dissapear (?)
>>
>> If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed stop) then the messages dissapear forever and everything seems to work fine after that (???). Starting the cpuspeed daemon makes the messages return.
>>
>> I hacked the jmess code and made sure it is doing what jack_connect is doing and the problem still happens. I then added a delay between connection calls and everything is fine for a while, while jmess is making the connections (ie: I don't get messages) but at some point the messages start appearing and that's it.
>>
>> Time for dinner.....
>>
> You don't say what is the Jack DSP CPU value when those XRun start to appear... If your machine is almost fully loaded (in "On Demand" case) then the message could make sense.
>
> Can you check the DSP CPU load?

I should have mentioned this. No, the CPU is not near overload (as shown
in top or the gnome cpu load indicators). I will double check to see if
I can see any peaks in individual processors.

On the other hand the load should be constant through the connection
processs, right? All clients are always processing audio all the time
(ie: load not changing), then I start making connections and at some
point the system goes nuts.

But of course the fact that changing the governor and then completely
stopping the cpuspeed daemon is making a difference would point to a cpu
load problem.

This is on a Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz laptop with
hyperthreading enabled.

-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Stéphane Letz

Le 10 déc. 2010 à 19:21, Fernando Lopez-Lezcano a écrit :

> On 12/10/2010 01:38 AM, Stéphane Letz wrote:
>>
>> Le 10 déc. 2010 à 04:51, Fernando Lopez-Lezcano a écrit :
>>
>>> I have run into a most puzzling problem. It is a long story but the end result could be summarized as:
>>>
>>> - start jack (1.9.6)
>>> - start a bunch of jack clients with many ports (sooperlooper, supercollider, 4 x zita-rev1...)
>>> - run jmess to disconnect everything first and then connect ports listed in an xml file
>>>
>>> If you run jmess jackd is left in a weird state, it keeps printing:
>>>
>>> ----
>>>
>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>
>>> JackAudioDriver::ProcessAsync Process error
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>
>>> JackAudioDriver::ProcessAsync Process error
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> ----
>>>
>>> That keeps going forever (AFAICT). Apparently the only client affected is SuperCollider (which is the one generating the most system load). I just tried not including SuperCollider (ie: running jmess without SC started) and I get no errors.
>>>
>>> But it gets weirder.
>>>
>>> If I switch the cpu speed governor to "Performance" mode (from "On Demand") then the messages stop. Or if I change the governor and then do all the connections with jmess then I get some messages but they stop. But jackd is now very touchy and pretty much anything I do on the computer generates messages like this one:
>>>
>>> ----
>>>
>>> 19:25:42.934 XRUN callback (385).
>>>
>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>
>>> JackAudioDriver::ProcessAsync Process error
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> JackPosixMutex::Unlock res = 1
>>>
>>> ----
>>>
>>> If I disconnect all ports the messages dissapear (?)
>>>
>>> If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed stop) then the messages dissapear forever and everything seems to work fine after that (???). Starting the cpuspeed daemon makes the messages return.
>>>
>>> I hacked the jmess code and made sure it is doing what jack_connect is doing and the problem still happens. I then added a delay between connection calls and everything is fine for a while, while jmess is making the connections (ie: I don't get messages) but at some point the messages start appearing and that's it.
>>>
>>> Time for dinner.....
>>>
>> You don't say what is the Jack DSP CPU value when those XRun start to appear... If your machine is almost fully loaded (in "On Demand" case) then the message could make sense.
>>
>> Can you check the DSP CPU load?
>
> I should have mentioned this. No, the CPU is not near overload (as shown in top or the gnome cpu load indicators). I will double check to see if I can see any peaks in individual processors.
>
> On the other hand the load should be constant through the connection processs, right? All clients are always processing audio all the time (ie: load not changing), then I start making connections and at some point the system goes nuts.

When you change connections, then you change the graph topology and because of jack2 parallelism activation, you may end up in a graph which complete computation exceeds DSP CPU (remember this is the part of the "buffer size duration" that will be taken to process the whole graph)
>
> But of course the fact that changing the governor and then completely stopping the cpuspeed daemon is making a difference would point to a cpu load problem.
>
> This is on a Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz laptop with hyperthreading enabled.
>


Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 10:25 AM, Stéphane Letz wrote:

>
> Le 10 déc. 2010 à 19:21, Fernando Lopez-Lezcano a écrit :
>
>> On 12/10/2010 01:38 AM, Stéphane Letz wrote:
>>>
>>> Le 10 déc. 2010 à 04:51, Fernando Lopez-Lezcano a écrit :
>>>
>>>> I have run into a most puzzling problem. It is a long story but the end result could be summarized as:
>>>>
>>>> - start jack (1.9.6)
>>>> - start a bunch of jack clients with many ports (sooperlooper, supercollider, 4 x zita-rev1...)
>>>> - run jmess to disconnect everything first and then connect ports listed in an xml file
>>>>
>>>> If you run jmess jackd is left in a weird state, it keeps printing:
>>>>
>>>> ----
>>>>
>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>
>>>> JackAudioDriver::ProcessAsync Process error
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>
>>>> JackAudioDriver::ProcessAsync Process error
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> ----
>>>>
>>>> That keeps going forever (AFAICT). Apparently the only client affected is SuperCollider (which is the one generating the most system load). I just tried not including SuperCollider (ie: running jmess without SC started) and I get no errors.
>>>>
>>>> But it gets weirder.
>>>>
>>>> If I switch the cpu speed governor to "Performance" mode (from "On Demand") then the messages stop. Or if I change the governor and then do all the connections with jmess then I get some messages but they stop. But jackd is now very touchy and pretty much anything I do on the computer generates messages like this one:
>>>>
>>>> ----
>>>>
>>>> 19:25:42.934 XRUN callback (385).
>>>>
>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>
>>>> JackAudioDriver::ProcessAsync Process error
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> JackPosixMutex::Unlock res = 1
>>>>
>>>> ----
>>>>
>>>> If I disconnect all ports the messages dissapear (?)
>>>>
>>>> If I stop the cpuspeed daemon in the computer (/sbin/service cpuspeed stop) then the messages dissapear forever and everything seems to work fine after that (???). Starting the cpuspeed daemon makes the messages return.
>>>>
>>>> I hacked the jmess code and made sure it is doing what jack_connect is doing and the problem still happens. I then added a delay between connection calls and everything is fine for a while, while jmess is making the connections (ie: I don't get messages) but at some point the messages start appearing and that's it.
>>>>
>>>> Time for dinner.....
>>>>
>>> You don't say what is the Jack DSP CPU value when those XRun start to appear... If your machine is almost fully loaded (in "On Demand" case) then the message could make sense.
>>>
>>> Can you check the DSP CPU load?
>>
>> I should have mentioned this. No, the CPU is not near overload (as shown in top or the gnome cpu load indicators). I will double check to see if I can see any peaks in individual processors.
>>
>> On the other hand the load should be constant through the connection processs, right? All clients are always processing audio all the time (ie: load not changing), then I start making connections and at some point the system goes nuts.
>
> When you change connections, then you change the graph topology and because of jack2 parallelism activation, you may end up in a graph which complete computation exceeds DSP CPU (remember this is the part of the "buffer size duration" that will be taken to process the whole graph)

I understand, but that is not what I'm seeing here (apparently).

I fired up system monitor which shows a rolling graph of cpu usage for
all four cores (2 real, 2 hyperthreaded). Load changes as processes
migrate over different cores, but none of them (at 1.2GHz speed - still
using the On Demand governer) shows more than 60% usage.

Now I fire up jmess which slowly builds up connections (I have a usleep
300000 between connections). The load does not go up substantially as a
result. The problem starts and the load is still roughly the same, say
not over 60% in all cpus. Jackd and its clients are spewing messages all
the time while this is happening. I remove all connections and the
messages go away. But again the load does not change significantly.

Maybe I'm doing something wrong but if load were the problem (and I
agree other facts point to that) I would expect to see at least one cpu
pegged at 100% but that does not seem to be happening.

-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 10:52 AM, Fernando Lopez-Lezcano wrote:

> On 12/10/2010 10:25 AM, Stéphane Letz wrote:
>>
>> Le 10 déc. 2010 à 19:21, Fernando Lopez-Lezcano a écrit :
>>
>>> On 12/10/2010 01:38 AM, Stéphane Letz wrote:
>>>>
>>>> Le 10 déc. 2010 à 04:51, Fernando Lopez-Lezcano a écrit :
>>>>
>>>>> I have run into a most puzzling problem. It is a long story but
>>>>> the end result could be summarized as:
>>>>>
>>>>> - start jack (1.9.6)
>>>>> - start a bunch of jack clients with many ports (sooperlooper,
>>>>> supercollider, 4 x zita-rev1...)
>>>>> - run jmess to disconnect everything first and then connect ports
>>>>> listed in an xml file
>>>>>
>>>>> If you run jmess jackd is left in a weird state, it keeps printing:
>>>>>
>>>>> ----
>>>>>
>>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>>
>>>>> JackAudioDriver::ProcessAsync Process error
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>>
>>>>> JackAudioDriver::ProcessAsync Process error
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> ----
>>>>>
>>>>> That keeps going forever (AFAICT). Apparently the only client
>>>>> affected is SuperCollider (which is the one generating the most
>>>>> system load). I just tried not including SuperCollider (ie:
>>>>> running jmess without SC started) and I get no errors.
>>>>>
>>>>> But it gets weirder.
>>>>>
>>>>> If I switch the cpu speed governor to "Performance" mode (from "On
>>>>> Demand") then the messages stop. Or if I change the governor and
>>>>> then do all the connections with jmess then I get some messages
>>>>> but they stop. But jackd is now very touchy and pretty much
>>>>> anything I do on the computer generates messages like this one:
>>>>>
>>>>> ----
>>>>>
>>>>> 19:25:42.934 XRUN callback (385).
>>>>>
>>>>> JackEngine::XRun: client = SuperCollider was not run: state = 2
>>>>>
>>>>> JackAudioDriver::ProcessAsync Process error
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> JackPosixMutex::Unlock res = 1
>>>>>
>>>>> ----
>>>>>
>>>>> If I disconnect all ports the messages dissapear (?)
>>>>>
>>>>> If I stop the cpuspeed daemon in the computer (/sbin/service
>>>>> cpuspeed stop) then the messages dissapear forever and everything
>>>>> seems to work fine after that (???). Starting the cpuspeed daemon
>>>>> makes the messages return.
>>>>>
>>>>> I hacked the jmess code and made sure it is doing what
>>>>> jack_connect is doing and the problem still happens. I then added
>>>>> a delay between connection calls and everything is fine for a
>>>>> while, while jmess is making the connections (ie: I don't get
>>>>> messages) but at some point the messages start appearing and
>>>>> that's it.
>>>>>
>>>>> Time for dinner.....
>>>>>
>>>> You don't say what is the Jack DSP CPU value when those XRun start
>>>> to appear... If your machine is almost fully loaded (in "On Demand"
>>>> case) then the message could make sense.
>>>>
>>>> Can you check the DSP CPU load?
>>>
>>> I should have mentioned this. No, the CPU is not near overload (as
>>> shown in top or the gnome cpu load indicators). I will double check
>>> to see if I can see any peaks in individual processors.
>>>
>>> On the other hand the load should be constant through the connection
>>> processs, right? All clients are always processing audio all the
>>> time (ie: load not changing), then I start making connections and at
>>> some point the system goes nuts.
>>
>> When you change connections, then you change the graph topology and
>> because of jack2 parallelism activation, you may end up in a graph
>> which complete computation exceeds DSP CPU (remember this is the part
>> of the "buffer size duration" that will be taken to process the whole
>> graph)
>
> I understand, but that is not what I'm seeing here (apparently).
>
> I fired up system monitor which shows a rolling graph of cpu usage for
> all four cores (2 real, 2 hyperthreaded). Load changes as processes
> migrate over different cores, but none of them (at 1.2GHz speed -
> still using the On Demand governer) shows more than 60% usage.
>
> Now I fire up jmess which slowly builds up connections (I have a
> usleep 300000 between connections). The load does not go up
> substantially as a result. The problem starts and the load is still
> roughly the same, say not over 60% in all cpus. Jackd and its clients
> are spewing messages all the time while this is happening. I remove
> all connections and the messages go away. But again the load does not
> change significantly.
>
> Maybe I'm doing something wrong but if load were the problem (and I
> agree other facts point to that) I would expect to see at least one
> cpu pegged at 100% but that does not seem to be happening.

Just to add one more confusing data point: the cpu usage field in
qjackctl does show 97/98% cpu usage when the errors are being triggered
(shows between 60 and 70% with no connections active).

But cpuspeed does _not_ change the cpu speed as a result. System Monitor
does not show one cpu pegged (it does not show any overall changes in
load). Top shows normal system loads (no significant changes). It would
seem that somehow jackd thinks a processor is pegged to 100% but it is
not. Or the System Monitor and top are not showing the right load for
the cpus.

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Paul Davis
On Fri, Dec 10, 2010 at 2:02 PM, Fernando Lopez-Lezcano
<[hidden email]> wrote:
 It would seem that
> somehow jackd thinks a processor is pegged to 100% but it is not. Or the
> System Monitor and top are not showing the right load for the cpus.

the jack dsp load is not based on any direct measurement of cpu load.

its the fraction of the period size/time that is used to actually run
the graph for 1 period.

so if the period size is 5msec and it takes 2.5msec to run the period,
the DSP load will be 50%.

it doesn't really correlate particularly strongly to CPU load (partly
because of RT scheduling)

--p
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
In reply to this post by Fernando Lopez-Lezcano
On 12/10/2010 11:02 AM, Fernando Lopez-Lezcano wrote:

> On 12/10/2010 10:52 AM, Fernando Lopez-Lezcano wrote:
>> On 12/10/2010 10:25 AM, Stéphane Letz wrote:
>>>
>>> Le 10 déc. 2010 à 19:21, Fernando Lopez-Lezcano a écrit :
>>>
>>>> On 12/10/2010 01:38 AM, Stéphane Letz wrote:
>>>>>
>>>>> Can you check the DSP CPU load?
>>>>
>>>> I should have mentioned this. No, the CPU is not near overload (as
>>>> shown in top or the gnome cpu load indicators). I will double check
>>>> to see if I can see any peaks in individual processors.
>>>>
>>>> On the other hand the load should be constant through the connection
>>>> processs, right? All clients are always processing audio all the
>>>> time (ie: load not changing), then I start making connections and at
>>>> some point the system goes nuts.
>>>
>>> When you change connections, then you change the graph topology and
>>> because of jack2 parallelism activation, you may end up in a graph
>>> which complete computation exceeds DSP CPU (remember this is the part
>>> of the "buffer size duration" that will be taken to process the whole
>>> graph)
>>
>> I understand, but that is not what I'm seeing here (apparently).
>>
>> I fired up system monitor which shows a rolling graph of cpu usage for
>> all four cores (2 real, 2 hyperthreaded). Load changes as processes
>> migrate over different cores, but none of them (at 1.2GHz speed -
>> still using the On Demand governer) shows more than 60% usage.
>>
>> Now I fire up jmess which slowly builds up connections (I have a
>> usleep 300000 between connections). The load does not go up
>> substantially as a result. The problem starts and the load is still
>> roughly the same, say not over 60% in all cpus. Jackd and its clients
>> are spewing messages all the time while this is happening. I remove
>> all connections and the messages go away. But again the load does not
>> change significantly.
>>
>> Maybe I'm doing something wrong but if load were the problem (and I
>> agree other facts point to that) I would expect to see at least one
>> cpu pegged at 100% but that does not seem to be happening.
>
> Just to add one more confusing data point: the cpu usage field in
> qjackctl does show 97/98% cpu usage when the errors are being triggered
> (shows between 60 and 70% with no connections active).
>
> But cpuspeed does _not_ change the cpu speed as a result. System Monitor
> does not show one cpu pegged (it does not show any overall changes in
> load). Top shows normal system loads (no significant changes). It would
> seem that somehow jackd thinks a processor is pegged to 100% but it is
> not. Or the System Monitor and top are not showing the right load for
> the cpus.

I just connected all ports manually one by one in qjackctl. One
connection in particular apparently triggers the problem.

In this test I am running sooperlooper (16 mono loopers) and two
instances of scsynth (SC's synth engine). When I connect a particular
output of the second instance of scsynth to an input of the first
instance the system starts going nuts. I disconnect it and it goes sane
again.

Just a heads up. I'll start looking into how the heck this could be
triggering this behavior......

-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 11:32 AM, Fernando Lopez-Lezcano wrote:

> On 12/10/2010 11:02 AM, Fernando Lopez-Lezcano wrote:
>> On 12/10/2010 10:52 AM, Fernando Lopez-Lezcano wrote:
>>> On 12/10/2010 10:25 AM, Stéphane Letz wrote:
>>>>
>>>> Le 10 déc. 2010 à 19:21, Fernando Lopez-Lezcano a écrit :
>>>>
>>>>> On 12/10/2010 01:38 AM, Stéphane Letz wrote:
>>>>>>
>>>>>> Can you check the DSP CPU load?
>>>>>
>>>>> I should have mentioned this. No, the CPU is not near overload (as
>>>>> shown in top or the gnome cpu load indicators). I will double check
>>>>> to see if I can see any peaks in individual processors.
>>>>>
>>>>> On the other hand the load should be constant through the connection
>>>>> processs, right? All clients are always processing audio all the
>>>>> time (ie: load not changing), then I start making connections and at
>>>>> some point the system goes nuts.
>>>>
>>>> When you change connections, then you change the graph topology and
>>>> because of jack2 parallelism activation, you may end up in a graph
>>>> which complete computation exceeds DSP CPU (remember this is the part
>>>> of the "buffer size duration" that will be taken to process the whole
>>>> graph)
>>>
>>> I understand, but that is not what I'm seeing here (apparently).
>>>
>>> I fired up system monitor which shows a rolling graph of cpu usage for
>>> all four cores (2 real, 2 hyperthreaded). Load changes as processes
>>> migrate over different cores, but none of them (at 1.2GHz speed -
>>> still using the On Demand governer) shows more than 60% usage.
>>>
>>> Now I fire up jmess which slowly builds up connections (I have a
>>> usleep 300000 between connections). The load does not go up
>>> substantially as a result. The problem starts and the load is still
>>> roughly the same, say not over 60% in all cpus. Jackd and its clients
>>> are spewing messages all the time while this is happening. I remove
>>> all connections and the messages go away. But again the load does not
>>> change significantly.
>>>
>>> Maybe I'm doing something wrong but if load were the problem (and I
>>> agree other facts point to that) I would expect to see at least one
>>> cpu pegged at 100% but that does not seem to be happening.
>>
>> Just to add one more confusing data point: the cpu usage field in
>> qjackctl does show 97/98% cpu usage when the errors are being triggered
>> (shows between 60 and 70% with no connections active).
>>
>> But cpuspeed does _not_ change the cpu speed as a result. System Monitor
>> does not show one cpu pegged (it does not show any overall changes in
>> load). Top shows normal system loads (no significant changes). It would
>> seem that somehow jackd thinks a processor is pegged to 100% but it is
>> not. Or the System Monitor and top are not showing the right load for
>> the cpus.
>
> I just connected all ports manually one by one in qjackctl. One
> connection in particular apparently triggers the problem.
>
> In this test I am running sooperlooper (16 mono loopers) and two
> instances of scsynth (SC's synth engine). When I connect a particular
> output of the second instance of scsynth to an input of the first
> instance the system starts going nuts. I disconnect it and it goes sane
> again.
>
> Just a heads up. I'll start looking into how the heck this could be
> triggering this behavior......

Nothing strange that I can see.
Connections are as follows:

sooperlooper:loop*_out_1 to SuperCollider:in* (16 channels)
sooperlooper:loop*_out_1 to SuperCollider-01:in* (16 channels)

SuperCollider:out_* to system:in_* (16 channels wide)
SuperCollider:out_20 to SuperCollider:in_20

SuperCollider-01:out_* to system:in_* (16 channels wide)

system:capture_1 to sooperlooper:common_in_1
system:capture_1 to sooperlooper:common_in_2

system:capture_1 to SuperCollider:in_17

system:capture_1 to SuperCollider-01:in_17

And then:

any connection made from SuperCollider-01:out_x to SuperCollider:in_x
triggers the messages...

-- Fernando
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fons Adriaensen-2
In reply to this post by Fernando Lopez-Lezcano
On Fri, Dec 10, 2010 at 11:32:42AM -0800, Fernando Lopez-Lezcano wrote:

> In this test I am running sooperlooper (16 mono loopers) and two
> instances of scsynth (SC's synth engine). When I connect a
> particular output of the second instance of scsynth to an input of
> the first instance the system starts going nuts. I disconnect it and
> it goes sane again.

Smells like 'denormals, Nans and Infs'.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 12:54 PM, [hidden email] wrote:
> On Fri, Dec 10, 2010 at 11:32:42AM -0800, Fernando Lopez-Lezcano wrote:
>
>> In this test I am running sooperlooper (16 mono loopers) and two
>> instances of scsynth (SC's synth engine). When I connect a
>> particular output of the second instance of scsynth to an input of
>> the first instance the system starts going nuts. I disconnect it and
>> it goes sane again.
> Smells like 'denormals, Nans and Infs'.
That's a good suggestion! I'll check for that (maybe bitmeter?) when I
get back home.
Thanks.
-- Fernando

PS: I have seen problems with denormals in sooperlooper but never in sc
before.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Stéphane Letz
In reply to this post by Paul Davis

Le 10 déc. 2010 à 20:05, Paul Davis a écrit :

> On Fri, Dec 10, 2010 at 2:02 PM, Fernando Lopez-Lezcano
> <[hidden email]> wrote:
> It would seem that
>> somehow jackd thinks a processor is pegged to 100% but it is not. Or the
>> System Monitor and top are not showing the right load for the cpus.
>
> the jack dsp load is not based on any direct measurement of cpu load.
>
> its the fraction of the period size/time that is used to actually run
> the graph for 1 period.
>
> so if the period size is 5msec and it takes 2.5msec to run the period,
> the DSP load will be 50%.
>
> it doesn't really correlate particularly strongly to CPU load (partly
> because of RT scheduling)
>
> --p


Yes. Paul is right, the point is not CPU load but *JACK* DSP (cpu) load. As soon as you approach 100%   (denormals issue or anything...) the XRun start to occur.

Stéphane
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
In reply to this post by Fernando Lopez-Lezcano
On 12/10/2010 03:10 PM, Fernando Lopez-Lezcano wrote:

> On 12/10/2010 12:54 PM, [hidden email] wrote:
>> On Fri, Dec 10, 2010 at 11:32:42AM -0800, Fernando Lopez-Lezcano wrote:
>>
>>> In this test I am running sooperlooper (16 mono loopers) and two
>>> instances of scsynth (SC's synth engine). When I connect a
>>> particular output of the second instance of scsynth to an input of
>>> the first instance the system starts going nuts. I disconnect it and
>>> it goes sane again.
>> Smells like 'denormals, Nans and Infs'.
> That's a good suggestion! I'll check for that (maybe bitmeter?) when I
> get back home.

Nope, that does not appear to be it. The first test I just did is to
send the troublesome connection (SuperCollider-01:out_20) to bitmeter.
Nothing shows up. No signal. If I also connect SuperCollider-01:out_20
to SuperCollider:in_20 trouble begins again. It may be denormals
somewhere else, I'll keep testing (keep in mind that stopping the
cpuspeed service gets rid of the problem! nothing makes sense!).

In fact, it appears that any port of SuperCollider-01 connected to any
port of SuperCollider brings trouble. It should be something dumb that
I'm doing but what?

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 04:33 PM, Fernando Lopez-Lezcano wrote:

> On 12/10/2010 03:10 PM, Fernando Lopez-Lezcano wrote:
>> On 12/10/2010 12:54 PM, [hidden email] wrote:
>>> On Fri, Dec 10, 2010 at 11:32:42AM -0800, Fernando Lopez-Lezcano wrote:
>>>
>>>> In this test I am running sooperlooper (16 mono loopers) and two
>>>> instances of scsynth (SC's synth engine). When I connect a
>>>> particular output of the second instance of scsynth to an input of
>>>> the first instance the system starts going nuts. I disconnect it and
>>>> it goes sane again.
>>> Smells like 'denormals, Nans and Infs'.
>> That's a good suggestion! I'll check for that (maybe bitmeter?) when
>> I get back home.
>
> Nope, that does not appear to be it. The first test I just did is to
> send the troublesome connection (SuperCollider-01:out_20) to bitmeter.
> Nothing shows up. No signal. If I also connect SuperCollider-01:out_20
> to SuperCollider:in_20 trouble begins again. It may be denormals
> somewhere else, I'll keep testing (keep in mind that stopping the
> cpuspeed service gets rid of the problem! nothing makes sense!).
>
> In fact, it appears that any port of SuperCollider-01 connected to any
> port of SuperCollider brings trouble. It should be something dumb that
> I'm doing but what?

Looks like something weird is going on inside SuperCollider... stopping
all instruments makes the problem go away. I'm slowly zeroing into the
culprit...... thanks for your patience........

-- Fernando

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fons Adriaensen-2
On Fri, Dec 10, 2010 at 04:48:39PM -0800, Fernando Lopez-Lezcano wrote:

> Looks like something weird is going on inside SuperCollider...
> stopping all instruments makes the problem go away. I'm slowly
> zeroing into the culprit...... thanks for your patience........

Is this jack2 on an SMP machine ?

It could just be that making the connection forces everything
to be sequential - the equivalent of a single CPU.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: jmess vs. jack 1.9.6, lots of connections

Fernando Lopez-Lezcano
On 12/10/2010 05:10 PM, [hidden email] wrote:
> On Fri, Dec 10, 2010 at 04:48:39PM -0800, Fernando Lopez-Lezcano wrote:
>
>> Looks like something weird is going on inside SuperCollider...
>> stopping all instruments makes the problem go away. I'm slowly
>> zeroing into the culprit...... thanks for your patience........
> Is this jack2 on an SMP machine ?

Yes.

> It could just be that making the connection forces everything
> to be sequential - the equivalent of a single CPU.

Yes, that would explain it. But then I should see a change in the load
in all cpus and I don't see that (with the tools I have). But on the
other hand stopping cpuspeed fixes the problem, or at least the symptom
(the data I have so far is very very confusing!).

A moment ago I thought it was a case of "bad programmer, no cookie!"[*].
I found a coding problem in my software but fixing it does not make a
difference. Which means I'm not fixing it or I have not found it yet, or
the problem is somewhere else...

-- Fernando

[*] in this case: I'm running two instances of scsynth to distribute
load (because I was having problems that seemed to point to load even
though I could not _see_ the load, arghh - and I wanted to expand things
later). I have control generator synths and target audio synths in both
servers but I was wrongly creating the buses that connect them in just
one server - anyway, seemed like a good bug to trigger weird behavior
but apparently that's not it).

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
12