Csound Csound-dev Csound-tekno Search About

[Cs-dev] [ csound-Bugs-3305875 ] Csound5.13.0 Jacko and CsoundPerformKsmps(), etc

Date2011-05-22 17:14
From"SourceForge.net"
Subject[Cs-dev] [ csound-Bugs-3305875 ] Csound5.13.0 Jacko and CsoundPerformKsmps(), etc
Bugs item #3305875, was opened at 2011-05-22 13:11
Message generated for change (Comment added) made by david-bluecame
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=564599&aid=3305875&group_id=81968

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Csound API
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: David Bluecame (david-bluecame)
Assigned to: Nobody/Anonymous (nobody)
Summary: Csound5.13.0 Jacko and CsoundPerformKsmps(), etc

Initial Comment:
When using the Jacko opcodes JackoInit and JackoOn in the orchestra, the API functions CsoundPerformKsmps() and CsoundPerformBuffer() perform the entire score and not only the desired ksmps/buffer. This causes undesired behaviour in any host application using those API functions.

I've been wondering if this has been done on purpose to avoid closing the Jack connections after a ksmps or buffer is performed. However, I think that it should not affect those functions, just recommend not using them in Jacko orchestras.

Steps to reproduce:
* Start jack
* Create any normal orchestra/score. The orchestra should have the same ksmps value as the Jack you are using.
* Create this example program (for example, let's call it csound_api1.c)

#include 
#include 
int main(int argc, char **argv)
{
  CSOUND *csound = csoundCreate(NULL);
  int result = csoundCompile(csound, argc, argv);
int i=0;
  while (result == 0) {
    result = csoundPerformKsmps(csound);
	printf("i=%d\n", i);
	i++;
	}
  csoundDestroy(csound);
  return (result >= 0 ? 0 : result);
}

* Compile with:
csound_api1.c -o csound_api1  -lcsound

* Use with
./csound_api1  (and whatever options you use for csound as the orchestra filename, score filename, etc)

It should perform the score/orchestra normally, and it will output a lot of printout to stdout, one for each execution of CsoundScorePerformKsmps(). This is the normal and expected behaviour.

* Now, add the following in the orchestra, just below the ksmps, sr, etc, settings
   JackoInit		"default", "csound"
   JackoOn 1

* Use with
./csound_api1  (and whatever options you use for csound as the orchestra filename, score filename, etc)

It should perform now the entire score/orchestra normally, but this time only one or two lines of the stdout printout, so the entire score has been performed by a single CsoundScorePerformKsmps()!!. This is NOT the normal and expected behaviour.

Best regards. David.


----------------------------------------------------------------------

>Comment By: David Bluecame (david-bluecame)
Date: 2011-05-22 15:14

Message:
After a long time debugging the internal CsoundPerformKsmps code and going
nowhere (I have been investigating this for some weeks and getting almost
crazy), I think I found the "problem". It seems that the author of "Jacko"
opcodes, replaced the original csound processing thread by a new one of
his, and that's why the CsoundPerformKsmps and CsoundPerformBuffer
functions are somehow overriden.

The piece of code within jacko.cpp which does it, I think it's the
following:

  int processCsound()
  {

    int result = 0;
    // Here we must wait once and only once, in order to put
    // the original Csound processing thread to sleep --
    // but we must NOT put the Jack processing callback
    // to sleep when it comes here!
    if (jackActive && csoundActive) {
      csoundActive = false;
      // While Jack is processing, wait here.
      // The Jack process callback will then call csoundPerformKsmps
      // until the Csound performance is complete.
      result = pthread_mutex_lock(&conditionMutex);
      result = pthread_cond_wait(&csoundCondition, &conditionMutex);
      result = pthread_mutex_unlock(&conditionMutex);
    }

I don't really know how to proceed now. As this was the original intention
of the Jacko opcodes author, I guess that this is not going to be fixed.
However, for a project of mine I need to use CsoundPerformKsmps so I will
need probably to create my own jack opcodes or something :-((

Best regards!

----------------------------------------------------------------------

Comment By: David Bluecame (david-bluecame)
Date: 2011-05-22 13:16

Message:
A typo correction: to compile the example, gcc should be used:

gcc csound_api1.c -o csound_api1 -lcsound

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=564599&aid=3305875&group_id=81968

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net