Hi,
With a colleague, I am writing a Python program creating an AI that
recognize sound and video segments and can associate between them. It
is CPU heavy, so we use multiprocessing in python via zmq.

After running for (some random amount of) time, our Python program simply halts.
We've investigated the cause and found that it stops on the call to
PerformKsmps.

In the C source code, we've inserted some print statements, allowing
us to see that the lock is acquired but not released in
function csoundPerformKsmps in csound.c
here:
csoundLockMutex(csound->API_lock)

In addition, we have print statements in the first and last csound
instrument, to see if any sections of csound instrument code is run.
These do not print when the program halts.
So, lock aquired, but csound is not processing ksmps for that k-pass.

There are no other csound instruments running, so we are quite sure
that it is not csound instrument code or csound opcode code that
creates the problem.

We tried running csound with -j1 on the command line to be absolutely
sure that csound is not trying to do multiprocessing. We do not need
the audio processing to be multiprocess, we use parallelism for the
more CPU heavy AI tasks.

We are investigating further details, but I wanted to ask for ideas as
to what can cause this kind of random glitch in csoundPerformKsmps.


-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

.... and what kind of haywire would I find myself in if I simply
remove the mutexes in csound.c csoundPerformKsmps ?

2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
> Hi,
> With a colleague, I am writing a Python program creating an AI that
> recognize sound and video segments and can associate between them. It
> is CPU heavy, so we use multiprocessing in python via zmq.
>
> After running for (some random amount of) time, our Python program simply halts.
> We've investigated the cause and found that it stops on the call to
> PerformKsmps.
>
> In the C source code, we've inserted some print statements, allowing
> us to see that the lock is acquired but not released in
> function csoundPerformKsmps in csound.c
> here:
> csoundLockMutex(csound->API_lock)
>
> In addition, we have print statements in the first and last csound
> instrument, to see if any sections of csound instrument code is run.
> These do not print when the program halts.
> So, lock aquired, but csound is not processing ksmps for that k-pass.
>
> There are no other csound instruments running, so we are quite sure
> that it is not csound instrument code or csound opcode code that
> creates the problem.
>
> We tried running csound with -j1 on the command line to be absolutely
> sure that csound is not trying to do multiprocessing. We do not need
> the audio processing to be multiprocess, we use parallelism for the
> more CPU heavy AI tasks.
>
> We are investigating further details, but I wanted to ask for ideas as
> to what can cause this kind of random glitch in csoundPerformKsmps.
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

More closely,
it halts on csound->spinrecv in kperf_nodebug


2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
> .... and what kind of haywire would I find myself in if I simply
> remove the mutexes in csound.c csoundPerformKsmps ?
>
> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>> Hi,
>> With a colleague, I am writing a Python program creating an AI that
>> recognize sound and video segments and can associate between them. It
>> is CPU heavy, so we use multiprocessing in python via zmq.
>>
>> After running for (some random amount of) time, our Python program simply halts.
>> We've investigated the cause and found that it stops on the call to
>> PerformKsmps.
>>
>> In the C source code, we've inserted some print statements, allowing
>> us to see that the lock is acquired but not released in
>> function csoundPerformKsmps in csound.c
>> here:
>> csoundLockMutex(csound->API_lock)
>>
>> In addition, we have print statements in the first and last csound
>> instrument, to see if any sections of csound instrument code is run.
>> These do not print when the program halts.
>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>
>> There are no other csound instruments running, so we are quite sure
>> that it is not csound instrument code or csound opcode code that
>> creates the problem.
>>
>> We tried running csound with -j1 on the command line to be absolutely
>> sure that csound is not trying to do multiprocessing. We do not need
>> the audio processing to be multiprocess, we use parallelism for the
>> more CPU heavy AI tasks.
>>
>> We are investigating further details, but I wanted to ask for ideas as
>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It smells like a bug. Can you file an issue? I vaguely remember fixing something to do with a lock that
was flag in one of our coverity tests. Is the code that you are using from git develop?

========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 5 Nov 2014, at 18:21, Oeyvind Brandtsegg  wrote:
> 
> More closely,
> it halts on csound->spinrecv in kperf_nodebug
> 
> 
> 2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
>> .... and what kind of haywire would I find myself in if I simply
>> remove the mutexes in csound.c csoundPerformKsmps ?
>> 
>> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>>> Hi,
>>> With a colleague, I am writing a Python program creating an AI that
>>> recognize sound and video segments and can associate between them. It
>>> is CPU heavy, so we use multiprocessing in python via zmq.
>>> 
>>> After running for (some random amount of) time, our Python program simply halts.
>>> We've investigated the cause and found that it stops on the call to
>>> PerformKsmps.
>>> 
>>> In the C source code, we've inserted some print statements, allowing
>>> us to see that the lock is acquired but not released in
>>> function csoundPerformKsmps in csound.c
>>> here:
>>> csoundLockMutex(csound->API_lock)
>>> 
>>> In addition, we have print statements in the first and last csound
>>> instrument, to see if any sections of csound instrument code is run.
>>> These do not print when the program halts.
>>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>> 
>>> There are no other csound instruments running, so we are quite sure
>>> that it is not csound instrument code or csound opcode code that
>>> creates the problem.
>>> 
>>> We tried running csound with -j1 on the command line to be absolutely
>>> sure that csound is not trying to do multiprocessing. We do not need
>>> the audio processing to be multiprocess, we use parallelism for the
>>> more CPU heavy AI tasks.
>>> 
>>> We are investigating further details, but I wanted to ask for ideas as
>>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>> 
>>> 
>>> --
>>> 
>>> Oeyvind Brandtsegg
>>> Professor of Music Technology
>>> NTNU
>>> 7491 Trondheim
>>> Norway
>>> Cell: +47 92 203 205
>>> 
>>> http://flyndresang.no/
>>> http://www.partikkelaudio.com/
>>> http://soundcloud.com/brandtsegg
>>> http://soundcloud.com/t-emp
>> 
>> 
>> 
>> --
>> 
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>> 
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
> 
> 
> 
> -- 
> 
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
> 
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

it is from git develop yes.

I removed the locks just to test, and it still fails in the same location.
( csound->spinrecv in kperf_nodebug),
so I wonder if it could happen that jack simply fails to deliver the
audio input buffer?
Jack does not print any message to indicate an error, and it does not
stop or show any signs of misbehaviour,
but still, it seems odd that csound should halt on reading samples
from audio in?



2014-11-05 19:28 GMT+01:00 Victor Lazzarini :
> It smells like a bug. Can you file an issue? I vaguely remember fixing something to do with a lock that
> was flag in one of our coverity tests. Is the code that you are using from git develop?
>
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 5 Nov 2014, at 18:21, Oeyvind Brandtsegg  wrote:
>>
>> More closely,
>> it halts on csound->spinrecv in kperf_nodebug
>>
>>
>> 2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
>>> .... and what kind of haywire would I find myself in if I simply
>>> remove the mutexes in csound.c csoundPerformKsmps ?
>>>
>>> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>>>> Hi,
>>>> With a colleague, I am writing a Python program creating an AI that
>>>> recognize sound and video segments and can associate between them. It
>>>> is CPU heavy, so we use multiprocessing in python via zmq.
>>>>
>>>> After running for (some random amount of) time, our Python program simply halts.
>>>> We've investigated the cause and found that it stops on the call to
>>>> PerformKsmps.
>>>>
>>>> In the C source code, we've inserted some print statements, allowing
>>>> us to see that the lock is acquired but not released in
>>>> function csoundPerformKsmps in csound.c
>>>> here:
>>>> csoundLockMutex(csound->API_lock)
>>>>
>>>> In addition, we have print statements in the first and last csound
>>>> instrument, to see if any sections of csound instrument code is run.
>>>> These do not print when the program halts.
>>>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>>>
>>>> There are no other csound instruments running, so we are quite sure
>>>> that it is not csound instrument code or csound opcode code that
>>>> creates the problem.
>>>>
>>>> We tried running csound with -j1 on the command line to be absolutely
>>>> sure that csound is not trying to do multiprocessing. We do not need
>>>> the audio processing to be multiprocess, we use parallelism for the
>>>> more CPU heavy AI tasks.
>>>>
>>>> We are investigating further details, but I wanted to ask for ideas as
>>>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>>>
>>>>
>>>> --
>>>>
>>>> Oeyvind Brandtsegg
>>>> Professor of Music Technology
>>>> NTNU
>>>> 7491 Trondheim
>>>> Norway
>>>> Cell: +47 92 203 205
>>>>
>>>> http://flyndresang.no/
>>>> http://www.partikkelaudio.com/
>>>> http://soundcloud.com/brandtsegg
>>>> http://soundcloud.com/t-emp
>>>
>>>
>>>
>>> --
>>>
>>> Oeyvind Brandtsegg
>>> Professor of Music Technology
>>> NTNU
>>> 7491 Trondheim
>>> Norway
>>> Cell: +47 92 203 205
>>>
>>> http://flyndresang.no/
>>> http://www.partikkelaudio.com/
>>> http://soundcloud.com/brandtsegg
>>> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

When I found that the problems stems from reading the audio input
buffer, I went and adjusted Jack to a higher priority and set a higher
timeout in Jack too. This has now been playing a sine tone since I
left last night so it seems the solution might work for me. I think it
would be reasonable to expect that Csound should just go on working
with what it has got in the case where the input buffer is not full
for some reason. The way it is now, it seems like it will wait until
the buffer is full and if it never is filled then Csound simply waits
forever. Could we have a timeout of sorts?
Oeyvind

2014-11-05 20:00 GMT+01:00 Oeyvind Brandtsegg :
> it is from git develop yes.
>
> I removed the locks just to test, and it still fails in the same location.
> ( csound->spinrecv in kperf_nodebug),
> so I wonder if it could happen that jack simply fails to deliver the
> audio input buffer?
> Jack does not print any message to indicate an error, and it does not
> stop or show any signs of misbehaviour,
> but still, it seems odd that csound should halt on reading samples
> from audio in?
>
>
>
> 2014-11-05 19:28 GMT+01:00 Victor Lazzarini :
>> It smells like a bug. Can you file an issue? I vaguely remember fixing something to do with a lock that
>> was flag in one of our coverity tests. Is the code that you are using from git develop?
>>
>> ========================
>> Dr Victor Lazzarini
>> Dean of Arts, Celtic Studies and Philosophy,
>> Maynooth University,
>> Maynooth, Co Kildare, Ireland
>> Tel: 00 353 7086936
>> Fax: 00 353 1 7086952
>>
>>> On 5 Nov 2014, at 18:21, Oeyvind Brandtsegg  wrote:
>>>
>>> More closely,
>>> it halts on csound->spinrecv in kperf_nodebug
>>>
>>>
>>> 2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
>>>> .... and what kind of haywire would I find myself in if I simply
>>>> remove the mutexes in csound.c csoundPerformKsmps ?
>>>>
>>>> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>>>>> Hi,
>>>>> With a colleague, I am writing a Python program creating an AI that
>>>>> recognize sound and video segments and can associate between them. It
>>>>> is CPU heavy, so we use multiprocessing in python via zmq.
>>>>>
>>>>> After running for (some random amount of) time, our Python program simply halts.
>>>>> We've investigated the cause and found that it stops on the call to
>>>>> PerformKsmps.
>>>>>
>>>>> In the C source code, we've inserted some print statements, allowing
>>>>> us to see that the lock is acquired but not released in
>>>>> function csoundPerformKsmps in csound.c
>>>>> here:
>>>>> csoundLockMutex(csound->API_lock)
>>>>>
>>>>> In addition, we have print statements in the first and last csound
>>>>> instrument, to see if any sections of csound instrument code is run.
>>>>> These do not print when the program halts.
>>>>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>>>>
>>>>> There are no other csound instruments running, so we are quite sure
>>>>> that it is not csound instrument code or csound opcode code that
>>>>> creates the problem.
>>>>>
>>>>> We tried running csound with -j1 on the command line to be absolutely
>>>>> sure that csound is not trying to do multiprocessing. We do not need
>>>>> the audio processing to be multiprocess, we use parallelism for the
>>>>> more CPU heavy AI tasks.
>>>>>
>>>>> We are investigating further details, but I wanted to ask for ideas as
>>>>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Oeyvind Brandtsegg
>>>>> Professor of Music Technology
>>>>> NTNU
>>>>> 7491 Trondheim
>>>>> Norway
>>>>> Cell: +47 92 203 205
>>>>>
>>>>> http://flyndresang.no/
>>>>> http://www.partikkelaudio.com/
>>>>> http://soundcloud.com/brandtsegg
>>>>> http://soundcloud.com/t-emp
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Oeyvind Brandtsegg
>>>> Professor of Music Technology
>>>> NTNU
>>>> 7491 Trondheim
>>>> Norway
>>>> Cell: +47 92 203 205
>>>>
>>>> http://flyndresang.no/
>>>> http://www.partikkelaudio.com/
>>>> http://soundcloud.com/brandtsegg
>>>> http://soundcloud.com/t-emp
>>>
>>>
>>>
>>> --
>>>
>>> Oeyvind Brandtsegg
>>> Professor of Music Technology
>>> NTNU
>>> 7491 Trondheim
>>> Norway
>>> Cell: +47 92 203 205
>>>
>>> http://flyndresang.no/
>>> http://www.partikkelaudio.com/
>>> http://soundcloud.com/brandtsegg
>>> http://soundcloud.com/t-emp
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
>
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

We can look into this, but what you describe seems what the code does, it keeps waiting until the buffer is full;  a
timeout might be implemented. Another solution is to rewrite the Jack code to be fully asynchronous (as the rtauhal code is).

Regards
========================
Dr Victor Lazzarini
Dean of Arts, Celtic Studies and Philosophy,
Maynooth University,
Maynooth, Co Kildare, Ireland
Tel: 00 353 7086936
Fax: 00 353 1 7086952 

> On 6 Nov 2014, at 07:53, Oeyvind Brandtsegg  wrote:
> 
> When I found that the problems stems from reading the audio input
> buffer, I went and adjusted Jack to a higher priority and set a higher
> timeout in Jack too. This has now been playing a sine tone since I
> left last night so it seems the solution might work for me. I think it
> would be reasonable to expect that Csound should just go on working
> with what it has got in the case where the input buffer is not full
> for some reason. The way it is now, it seems like it will wait until
> the buffer is full and if it never is filled then Csound simply waits
> forever. Could we have a timeout of sorts?
> Oeyvind
> 
> 2014-11-05 20:00 GMT+01:00 Oeyvind Brandtsegg :
>> it is from git develop yes.
>> 
>> I removed the locks just to test, and it still fails in the same location.
>> ( csound->spinrecv in kperf_nodebug),
>> so I wonder if it could happen that jack simply fails to deliver the
>> audio input buffer?
>> Jack does not print any message to indicate an error, and it does not
>> stop or show any signs of misbehaviour,
>> but still, it seems odd that csound should halt on reading samples
>> from audio in?
>> 
>> 
>> 
>> 2014-11-05 19:28 GMT+01:00 Victor Lazzarini :
>>> It smells like a bug. Can you file an issue? I vaguely remember fixing something to do with a lock that
>>> was flag in one of our coverity tests. Is the code that you are using from git develop?
>>> 
>>> ========================
>>> Dr Victor Lazzarini
>>> Dean of Arts, Celtic Studies and Philosophy,
>>> Maynooth University,
>>> Maynooth, Co Kildare, Ireland
>>> Tel: 00 353 7086936
>>> Fax: 00 353 1 7086952
>>> 
>>>> On 5 Nov 2014, at 18:21, Oeyvind Brandtsegg  wrote:
>>>> 
>>>> More closely,
>>>> it halts on csound->spinrecv in kperf_nodebug
>>>> 
>>>> 
>>>> 2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
>>>>> .... and what kind of haywire would I find myself in if I simply
>>>>> remove the mutexes in csound.c csoundPerformKsmps ?
>>>>> 
>>>>> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>>>>>> Hi,
>>>>>> With a colleague, I am writing a Python program creating an AI that
>>>>>> recognize sound and video segments and can associate between them. It
>>>>>> is CPU heavy, so we use multiprocessing in python via zmq.
>>>>>> 
>>>>>> After running for (some random amount of) time, our Python program simply halts.
>>>>>> We've investigated the cause and found that it stops on the call to
>>>>>> PerformKsmps.
>>>>>> 
>>>>>> In the C source code, we've inserted some print statements, allowing
>>>>>> us to see that the lock is acquired but not released in
>>>>>> function csoundPerformKsmps in csound.c
>>>>>> here:
>>>>>> csoundLockMutex(csound->API_lock)
>>>>>> 
>>>>>> In addition, we have print statements in the first and last csound
>>>>>> instrument, to see if any sections of csound instrument code is run.
>>>>>> These do not print when the program halts.
>>>>>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>>>>> 
>>>>>> There are no other csound instruments running, so we are quite sure
>>>>>> that it is not csound instrument code or csound opcode code that
>>>>>> creates the problem.
>>>>>> 
>>>>>> We tried running csound with -j1 on the command line to be absolutely
>>>>>> sure that csound is not trying to do multiprocessing. We do not need
>>>>>> the audio processing to be multiprocess, we use parallelism for the
>>>>>> more CPU heavy AI tasks.
>>>>>> 
>>>>>> We are investigating further details, but I wanted to ask for ideas as
>>>>>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> 
>>>>>> Oeyvind Brandtsegg
>>>>>> Professor of Music Technology
>>>>>> NTNU
>>>>>> 7491 Trondheim
>>>>>> Norway
>>>>>> Cell: +47 92 203 205
>>>>>> 
>>>>>> http://flyndresang.no/
>>>>>> http://www.partikkelaudio.com/
>>>>>> http://soundcloud.com/brandtsegg
>>>>>> http://soundcloud.com/t-emp
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Oeyvind Brandtsegg
>>>>> Professor of Music Technology
>>>>> NTNU
>>>>> 7491 Trondheim
>>>>> Norway
>>>>> Cell: +47 92 203 205
>>>>> 
>>>>> http://flyndresang.no/
>>>>> http://www.partikkelaudio.com/
>>>>> http://soundcloud.com/brandtsegg
>>>>> http://soundcloud.com/t-emp
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 
>>>> Oeyvind Brandtsegg
>>>> Professor of Music Technology
>>>> NTNU
>>>> 7491 Trondheim
>>>> Norway
>>>> Cell: +47 92 203 205
>>>> 
>>>> http://flyndresang.no/
>>>> http://www.partikkelaudio.com/
>>>> http://soundcloud.com/brandtsegg
>>>> http://soundcloud.com/t-emp
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
>> 
>> 
>> --
>> 
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>> 
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
> 
> 
> 
> -- 
> 
> Oeyvind Brandtsegg
> Professor of Music Technology
> NTNU
> 7491 Trondheim
> Norway
> Cell: +47 92 203 205
> 
> http://flyndresang.no/
> http://www.partikkelaudio.com/
> http://soundcloud.com/brandtsegg
> http://soundcloud.com/t-emp
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That is good.

I've updated the github issue accordingly



2014-11-06 10:22 GMT+01:00 Victor Lazzarini :
> We can look into this, but what you describe seems what the code does, it keeps waiting until the buffer is full;  a
> timeout might be implemented. Another solution is to rewrite the Jack code to be fully asynchronous (as the rtauhal code is).
>
> Regards
> ========================
> Dr Victor Lazzarini
> Dean of Arts, Celtic Studies and Philosophy,
> Maynooth University,
> Maynooth, Co Kildare, Ireland
> Tel: 00 353 7086936
> Fax: 00 353 1 7086952
>
>> On 6 Nov 2014, at 07:53, Oeyvind Brandtsegg  wrote:
>>
>> When I found that the problems stems from reading the audio input
>> buffer, I went and adjusted Jack to a higher priority and set a higher
>> timeout in Jack too. This has now been playing a sine tone since I
>> left last night so it seems the solution might work for me. I think it
>> would be reasonable to expect that Csound should just go on working
>> with what it has got in the case where the input buffer is not full
>> for some reason. The way it is now, it seems like it will wait until
>> the buffer is full and if it never is filled then Csound simply waits
>> forever. Could we have a timeout of sorts?
>> Oeyvind
>>
>> 2014-11-05 20:00 GMT+01:00 Oeyvind Brandtsegg :
>>> it is from git develop yes.
>>>
>>> I removed the locks just to test, and it still fails in the same location.
>>> ( csound->spinrecv in kperf_nodebug),
>>> so I wonder if it could happen that jack simply fails to deliver the
>>> audio input buffer?
>>> Jack does not print any message to indicate an error, and it does not
>>> stop or show any signs of misbehaviour,
>>> but still, it seems odd that csound should halt on reading samples
>>> from audio in?
>>>
>>>
>>>
>>> 2014-11-05 19:28 GMT+01:00 Victor Lazzarini :
>>>> It smells like a bug. Can you file an issue? I vaguely remember fixing something to do with a lock that
>>>> was flag in one of our coverity tests. Is the code that you are using from git develop?
>>>>
>>>> ========================
>>>> Dr Victor Lazzarini
>>>> Dean of Arts, Celtic Studies and Philosophy,
>>>> Maynooth University,
>>>> Maynooth, Co Kildare, Ireland
>>>> Tel: 00 353 7086936
>>>> Fax: 00 353 1 7086952
>>>>
>>>>> On 5 Nov 2014, at 18:21, Oeyvind Brandtsegg  wrote:
>>>>>
>>>>> More closely,
>>>>> it halts on csound->spinrecv in kperf_nodebug
>>>>>
>>>>>
>>>>> 2014-11-05 19:07 GMT+01:00 Oeyvind Brandtsegg :
>>>>>> .... and what kind of haywire would I find myself in if I simply
>>>>>> remove the mutexes in csound.c csoundPerformKsmps ?
>>>>>>
>>>>>> 2014-11-05 19:03 GMT+01:00 Oeyvind Brandtsegg :
>>>>>>> Hi,
>>>>>>> With a colleague, I am writing a Python program creating an AI that
>>>>>>> recognize sound and video segments and can associate between them. It
>>>>>>> is CPU heavy, so we use multiprocessing in python via zmq.
>>>>>>>
>>>>>>> After running for (some random amount of) time, our Python program simply halts.
>>>>>>> We've investigated the cause and found that it stops on the call to
>>>>>>> PerformKsmps.
>>>>>>>
>>>>>>> In the C source code, we've inserted some print statements, allowing
>>>>>>> us to see that the lock is acquired but not released in
>>>>>>> function csoundPerformKsmps in csound.c
>>>>>>> here:
>>>>>>> csoundLockMutex(csound->API_lock)
>>>>>>>
>>>>>>> In addition, we have print statements in the first and last csound
>>>>>>> instrument, to see if any sections of csound instrument code is run.
>>>>>>> These do not print when the program halts.
>>>>>>> So, lock aquired, but csound is not processing ksmps for that k-pass.
>>>>>>>
>>>>>>> There are no other csound instruments running, so we are quite sure
>>>>>>> that it is not csound instrument code or csound opcode code that
>>>>>>> creates the problem.
>>>>>>>
>>>>>>> We tried running csound with -j1 on the command line to be absolutely
>>>>>>> sure that csound is not trying to do multiprocessing. We do not need
>>>>>>> the audio processing to be multiprocess, we use parallelism for the
>>>>>>> more CPU heavy AI tasks.
>>>>>>>
>>>>>>> We are investigating further details, but I wanted to ask for ideas as
>>>>>>> to what can cause this kind of random glitch in csoundPerformKsmps.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Oeyvind Brandtsegg
>>>>>>> Professor of Music Technology
>>>>>>> NTNU
>>>>>>> 7491 Trondheim
>>>>>>> Norway
>>>>>>> Cell: +47 92 203 205
>>>>>>>
>>>>>>> http://flyndresang.no/
>>>>>>> http://www.partikkelaudio.com/
>>>>>>> http://soundcloud.com/brandtsegg
>>>>>>> http://soundcloud.com/t-emp
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Oeyvind Brandtsegg
>>>>>> Professor of Music Technology
>>>>>> NTNU
>>>>>> 7491 Trondheim
>>>>>> Norway
>>>>>> Cell: +47 92 203 205
>>>>>>
>>>>>> http://flyndresang.no/
>>>>>> http://www.partikkelaudio.com/
>>>>>> http://soundcloud.com/brandtsegg
>>>>>> http://soundcloud.com/t-emp
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Oeyvind Brandtsegg
>>>>> Professor of Music Technology
>>>>> NTNU
>>>>> 7491 Trondheim
>>>>> Norway
>>>>> Cell: +47 92 203 205
>>>>>
>>>>> http://flyndresang.no/
>>>>> http://www.partikkelaudio.com/
>>>>> http://soundcloud.com/brandtsegg
>>>>> http://soundcloud.com/t-emp
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>>
>>> Oeyvind Brandtsegg
>>> Professor of Music Technology
>>> NTNU
>>> 7491 Trondheim
>>> Norway
>>> Cell: +47 92 203 205
>>>
>>> http://flyndresang.no/
>>> http://www.partikkelaudio.com/
>>> http://soundcloud.com/brandtsegg
>>> http://soundcloud.com/t-emp
>>
>>
>>
>> --
>>
>> Oeyvind Brandtsegg
>> Professor of Music Technology
>> NTNU
>> 7491 Trondheim
>> Norway
>> Cell: +47 92 203 205
>>
>> http://flyndresang.no/
>> http://www.partikkelaudio.com/
>> http://soundcloud.com/brandtsegg
>> http://soundcloud.com/t-emp
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Oeyvind Brandtsegg
Professor of Music Technology
NTNU
7491 Trondheim
Norway
Cell: +47 92 203 205

http://flyndresang.no/
http://www.partikkelaudio.com/
http://soundcloud.com/brandtsegg
http://soundcloud.com/t-emp

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net