| Bugs item #3305875, was opened at 2011-05-22 15:11
Message generated for change (Comment added) made by veplaini
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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: David Bluecame (david-bluecame)
Assigned to: Victor Lazzarini (veplaini)
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: Victor Lazzarini (veplaini)
Date: 2011-05-22 17:39
Message:
Also: it is a good idea to ask these things in the csound developer's list.
You could save time (I would have told you that the jacko opcodes do that)
----------------------------------------------------------------------
Comment By: Victor Lazzarini (veplaini)
Date: 2011-05-22 17:38
Message:
This is a design issue by Mike Gogins, so I am marking it closed. I think
there is no fix actually, apart from removing the opcodes.
However note that you don't need to use the Jacko opcodes for Jack. Csound
has a Jack IO module, which has been there since the release of Csound 5.
All you need to use Jack is to set -+rtaudio=jack in your output options.
Mike probably wanted a different way to connect to Jack (I am not entirely
sure of his motives).
----------------------------------------------------------------------
Comment By: David Bluecame (david-bluecame)
Date: 2011-05-22 17: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 15: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 |