Calling performKsmps in a loop gives you the opportunity to bail out of a
performance. That's why CsoundVST does it that way. There is no performance
overhead.


Original Message:
-----------------
From:  ramsdell@mitre.org (John D. Ramsdell)
Date: 24 Sep 2003 08:40:29 -0400
To: csound-dev@eartha.mills.edu, ramsdell@mitre.org
Subject: [CSOUND-DEV:3096] CSound API with wxCSound


What is the proper way to invoke CSound via the CSound API?  Following
the instructions in csound.h, I wrote a C++ object with this form:

Synthesizer::Synthesizer()
  : m_csound(csoundCreate(this))
{
  ... set up callbacks
}

int Synthesizer::perform(int argc, char **argv)
{
  Main& app = wxGetApp();
  app.post_clear_plots();
  int rc = csoundCompile(m_csound, argc, argv);
  if (!rc)
    while(!csoundPerformBuffer(m_csound));
  csoundCleanup(m_csound);
  csoundReset(m_csound);
  return rc;
}

Maybe instead, I should be simply calling csoundPerform, then
csoundCleanup, and then csoundReset.  Then again, I notice the
CsoundVST calls csoundPerformKsmps instead of calling
csoundPerformBuffer in a while loop.  So what should I be doing in
wxCSound's perform method?

John


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

All righty then, I'll ape what CsoundVST does, and call
csoundPerformKsmps.

John

"gogins@pipeline.com"  writes:

> Calling performKsmps in a loop gives you the opportunity to bail out
> of a performance. That's why CsoundVST does it that way. There is no
> performance overhead.

I discovered the hard way that for wxCSound, one must call csoundPerform
instead of calling csoundCompile followed by either csoundPerformKsmps
or csoundPerformBuffer in a loop.  I cannot explain why, but the failure
to use csoundPerform results in weird memory errors that I find hard
to trace.  A run often produces segmentation faults.

If you are using a source release of either version 0.5.0 or 0.5.1 of
wxCSound, please update to 0.5.2 now.  If you have the Windows binary
release, please dump it.  I'll put out a new binary by the end of the
week.

John

diff -u -r1.6 synthesizer.cpp
--- src/wx/synthesizer.cpp	29 Sep 2003 10:22:41 -0000	1.6
+++ src/wx/synthesizer.cpp	30 Sep 2003 12:34:16 -0000
@@ -180,9 +180,7 @@
 {
   Main& app = wxGetApp();
   app.post_clear_plots();
-  int rc = csoundCompile(m_csound, argc, argv);
-  if (!rc)
-    while(!csoundPerformKsmps(m_csound));
+  int rc = csoundPerform(m_csound, argc, argv);
   csoundCleanup(m_csound);
   csoundReset(m_csound);
   return rc;
 

"gogins@pipeline.com"  writes:

> Calling performKsmps in a loop gives you the opportunity to bail out of a
> performance. That's why CsoundVST does it that way. There is no performance
> overhead.
> 
> 
> Original Message:
> -----------------
> From:  ramsdell@mitre.org (John D. Ramsdell)
> Date: 24 Sep 2003 08:40:29 -0400
> To: csound-dev@eartha.mills.edu, ramsdell@mitre.org
> Subject: [CSOUND-DEV:3096] CSound API with wxCSound
> 
> 
> What is the proper way to invoke CSound via the CSound API?  Following
> the instructions in csound.h, I wrote a C++ object with this form:
> 
> Synthesizer::Synthesizer()
>   : m_csound(csoundCreate(this))
> {
>   ... set up callbacks
> }
> 
> int Synthesizer::perform(int argc, char **argv)
> {
>   Main& app = wxGetApp();
>   app.post_clear_plots();
>   int rc = csoundCompile(m_csound, argc, argv);
>   if (!rc)
>     while(!csoundPerformBuffer(m_csound));
>   csoundCleanup(m_csound);
>   csoundReset(m_csound);
>   return rc;
> }
> 
> Maybe instead, I should be simply calling csoundPerform, then
> csoundCleanup, and then csoundReset.  Then again, I notice the
> CsoundVST calls csoundPerformKsmps instead of calling
> csoundPerformBuffer in a while loop.  So what should I be doing in
> wxCSound's perform method?
> 
> John

I being driven cRaZy by a problem I have with the CSound API.  Perhaps
I'm abusing it--hopely one of you will know if I am.

I have enclosed a short program that repeats the rendering of a csd
file twenty times.  On only Windows, after about ten runs, a
segmentation fault occurs in oload.  On Linux, I link using -lm, and
the program runs to completion.

John

/* 

CSound API driver showing the segmentation fault in oload.

On Windows 2000, install MinGW and MSYS.  Create libcsound.a by compiling
the latest CSound with the flags:

DEFS = -DSYS5 -DSSOUND -DWINDOWS -DSFIRCAM \
-DUSE_CSOUND_YIELD -DWX_GUI -DLOSE_MIDI_TTY -DLOSE_LOAD_LIBRARY

Ensure the following header and csd files are present.

$ ls
Makefile  csound.xmg  driver.c     libcsound.a  sysdep.h
csound.h  cwindow.h   knowing.csd  opcode.h
$ 

The URL for knowing.csd is:

http://www.ccs.neu.edu/home/ramsdell/papers/knowing/knowing.csd

Compile and link this file with:

CFLAGS = -g
LDLIBS = libcsound.a -lrpcrt4 -loleaut32 -lole32 -luuid \
-lwinspool -lwinmm -lshell32 -lcomctl32 -lctl3d32 -ladvapi32 -lwsock32

Run the program using gdb.  After about ten trials, you should see:

$ gdb driver.exe 
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) run
Starting program: C:\opt\msys-1.0\home\Administrator\bug\wx/driver.exe 

Program received signal SIGSEGV, Segmentation fault.
oload () at ../../../src/csound/oload.c:391
391             MYFLT conval = pool[inoffp->indx[0] - 1];
(gdb) 

*/

#include 
#include 
#include "csound.h"

static void wxcsound_message(void *csound, const char *format, va_list args)
{
  vprintf(format, args);
}

void csoundMessage0(const char *format, ...)
{
  va_list args;
  va_start(args, format);
  wxcsound_message(0, format, args);
  va_end(args);
}

static int wxcsound_poll_events(void *csound)
{
  return 1;
}

static const int n = 20;

static char *args[] = { "csound", "knowing.csd", 0 };

int main(int argc, char **argv)
{
  int i, rc;
  void *csound = csoundCreate(0);
  csoundSetMessageCallback(csound, wxcsound_message);
  csoundSetIsGraphable(csound, 0);
  csoundSetYieldCallback(csound, wxcsound_poll_events);

  if (argc != 1) {
    printf("Bad arg cound %d\n", argc);
    return 1;
  }
  args[0] = argv[0];

  for (i = 0; i < n; i++) {
    printf("Starting trial number %d\n", i + 1);
    rc = csoundPerform(csound, sizeof(args)/sizeof(*args) - 1, args);
    if (rc)
      return rc;
    csoundCleanup(csound);
    csoundReset(csound);
    rc = remove("knowing.aiff");
    if (rc) {
      perror("While deleting \"knowing.aiff\"");
      return rc;
    }
  }
  printf("Finished %d trials\n", n);
  return rc;
}

/* The Makefile:

TARGET = driver

CFLAGS = -g
LDLIBS = libcsound.a -lrpcrt4 -loleaut32 -lole32 -luuid \
-lwinspool -lwinmm -lshell32 -lcomctl32 -lctl3d32 -ladvapi32 -lwsock32

all:	$(TARGET)

clean:
	-rm $(TARGET).exe

*/

I discovered a few things about the segmentation fault I reported
earlier, and simplified the procedure for duplicating it.  To
duplicate the bug, just add the following two files into a directory
that has the current set of sources from the CVS repository, add in
knowing.csd from
http://www.ccs.neu.edu/home/ramsdell/papers/knowing/knowing.csd, and
then type "make".  The complete instructions are in the enclosed C
file.

I discovered that the presence of all the defines except SSOUND does
effect the bug, and they can be left undefined, however, if SSOUND is
not defined, the file sfont.c fails to compile.

John

ramsdell@mitre.org (John D. Ramsdell) writes:

> I being driven cRaZy by a problem I have with the CSound API.  Perhaps
> I'm abusing it--hopely one of you will know if I am.
> 
> I have enclosed a short program that repeats the rendering of a csd
> file twenty times.  On only Windows, after about ten runs, a
> segmentation fault occurs in oload.  On Linux, I link using -lm, and
> the program runs to completion.
> 
> John

I left out the word "not".  The second paragraph should have said:

I discovered that the presence of all the defines except SSOUND does
not effect the bug, and they can be left undefined, however, if SSOUND
is not defined, the file sfont.c fails to compile.

John