.h should match .c, yes.

All API functions should appear in csound.h, yes.

Ideally, no other Csound header files should need to be included to create software that embeds Csound, but this is not the case at this time.

Regards,
Mike


-----Original Message-----
From: Anthony Kozar 
Sent: May 16, 2005 2:13 PM
To: New Csound Developer list 
Subject: [Cs-dev] API discrepancies

I've noticed that csound.h and csound.c do not agree on the signatures for
many of the API calls.  Particularly with the calls to set callbacks, many
of the callback signatures appear to have changed in csound.c but not
csound.h.  I am assuming the information in csound.c is correct and will
make changes unless someone beats me to it.

Also, should not csound.h be a complete specification of the Csound API?
Many of the new calls do not appear to have been added.

Anthony



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel





-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 5/16/05 5:24 PM, Michael Gogins  etched in stone:

> .h should match .c, yes.

They do, I think -- my faults.

> All API functions should appear in csound.h, yes.
> 
> Ideally, no other Csound header files should need to be included to create
> software that embeds Csound, but this is not the case at this time.

I found that out while trying to add rt audio callbacks to the Mac host
today. (1)  Had to #include soundio.h and csoundCore.h, I think.

Anthony

(1)  Which by the way is now making noise -- literally.  Have the semantics
of the calls playopen and rtplay changed significantly with Csound 5?  I
just modified existing code to use the new function signatures, but I now
get a very noisy, stuttering output where things used to work in Cs4.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> > .h should match .c, yes.
> They do, I think -- my faults.

If course if they would not, there would be a compile error given that
csound.c #includes csound.h (by including csoundCore.h).

> I found that out while trying to add rt audio callbacks to the Mac host
> today. (1)  Had to #include soundio.h and csoundCore.h, I think.
> 
> Anthony
> 
> (1)  Which by the way is now making noise -- literally.  Have the semantics
> of the calls playopen and rtplay changed significantly with Csound 5?  I
> just modified existing code to use the new function signatures, but I now
> get a very noisy, stuttering output where things used to work in Cs4.

You may want to have a look at existing rt audio plugins (e.g. InOut/rtalsa.c),
but here is some information on the callbacks:

int (*playopen__)(void *csound, csRtAudioParams *parm);
int (*recopen_)(void *csound, csRtAudioParams *parm);

Both functions should return zero on success.
The csRtAudioParams structure contains the following:

   typedef struct {
     char    *devName;       /* device name (NULL/empty: default)           */
     int     devNum;         /* device number (0-1023), 1024: default       */
     int     bufSamp_SW;     /* buffer fragment size in samples             */
                             /*   (*not* multiplied by nchnls)              */
     int     bufSamp_HW;     /* total buffer size in samples ( = O.oMaxLag) */
     int     nChannels;      /* number of channels                          */
     int     sampleFormat;   /* sample format (AE_SHORT etc.)               */
     float   sampleRate;     /* sample rate in Hz                           */
   } csRtAudioParams;

void (*rtplay__)(void *csound, void *outBuf, int nbytes);
int (*rtrecord__)(void *csound, void *inBuf, int nbytes);

'outBuf' and 'inBuf' are pointers to arrays of MYFLT (that is probably why
you got noise, the callbacks are responsible for any format conversion, the
audio data passed from/to the Csound library is always MYFLT), of 'nbytes'
bytes (not samples or sample frames). The record callback should return the
number of bytes read (that is, normally the same as 'nbytes').

void (*rtclose__)(void *csound);

Closes both streams. Should be safe to call even if there are no actual streams
opened (or are already closed).

If you set the callbacks from the host application, rather than writing a
plugin library - I do not know if that works on MacOS, it should be done between
calling csoundPreCompile and csoundCompile:

csound = csoundCreate(...);
...
csoundPreCompile(csound);
...
set callbacks here
...
csoundCompile(csound);


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 5/17/05 5:30 AM, Istvan Varga  etched in stone:

> int (*playopen__)(void *csound, csRtAudioParams *parm);
> int (*recopen_)(void *csound, csRtAudioParams *parm);
> 
> Both functions should return zero on success.
> The csRtAudioParams structure contains the following:
> 
> typedef struct {
[...]
> } csRtAudioParams;

I found all of this in the code of course and adapted the Mac callbacks to
use the given information instead of reading Csound globals.

> void (*rtplay__)(void *csound, void *outBuf, int nbytes);
> int (*rtrecord__)(void *csound, void *inBuf, int nbytes);
> 
> 'outBuf' and 'inBuf' are pointers to arrays of MYFLT (that is probably why
> you got noise, the callbacks are responsible for any format conversion, the
> audio data passed from/to the Csound library is always MYFLT), of 'nbytes'
> bytes (not samples or sample frames). The record callback should return the
> number of bytes read (that is, normally the same as 'nbytes').

This is almost definitely the problem!  The Cs4 code assumed that outBuf and
inBuf had the format specified on the commandline (in this case, almost
always AE_SHORT).  Why is there a sampleFormat member in the csRtAudioParams
struct if Csound always sends MYFLTs?  Wouldn't it make more sense to have a
single piece of code (in Csound) for doing the type conversions so that each
implementor of a set of RT audio callbacks does not have to reimplement this
same code?

I am worried that if I write this code myself with all of the conversions
from float/double to short that it will not be very fast (I don't know any
optimizing tricks).  (I suppose that I could look to see what Csound did in
the past).

> void (*rtclose__)(void *csound);
> 
> Closes both streams. Should be safe to call even if there are no actual
> streams opened (or are already closed).

Thanks.  That is an important piece of information to know.

> If you set the callbacks from the host application, rather than writing a
> plugin library - I do not know if that works on MacOS, it should be done
> between calling csoundPreCompile and csoundCompile:

That is what I am doing now.  I actually figured this out the hard way after
a lot of code tracing, and scratching my head.  I was following the model in
csound_main.c which does not use csoundPreCompile.

I think after I'm done with this Mac work, I may look at improving the
documentation for each API call -- it really needs to be clear when each
call is valid to make.

Thanks, once again, for the helpful information !!  I should now be able to
get RT audio to work on MacOS 9 today.

:)

Anthony Kozar
anthonykozar@sbcglobal.net
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have real-time audio working via the API with Csound 5 now on MacOS 9.
Performance is not terrible but is slightly worse than it was under Csound
4.23. ++ (Cs4 could get through most portions of Trapped on my machine in RT
but the new implementation for Cs5 has more frequent (but minor) glitches).

I am wondering what I can do to speed up the code.  One problem (and another
surprise difference between Cs4 & 5) is that the MYFLT array from Csound is
scaled to 1.0 instead of the max amplitude for the output format.  I am
specifying -s to the library and was expecting 32767.0 to be 0 dB (because
that is what it is in the orchestra).  Thus it seems likely that Csound is
dividing each sample by 32767 and then I have to multuply it by that value
again before sending it to the DAC.  This seems like a waste of processor
cycles (especially on my 266MHz machine!).

Here is the core of the code I am using to copy samples in my rtplay:

// Copy the buffer from Csound (cannot just move bytes anymore; outbuf is
        MYFLTs)
// BlockMove(outbuf,&(iobufptr->buffer[iobufptr->writendx]), nbytes);
    bufferpos = &(iobufptr->buffer[iobufptr->writendx]);
    if  (myfltsize == 4) {
        fpos = (float*)outbuf;
        for (i = 0; i < nsamples; ++i)
            *bufferpos++ = (short)(32767.0f * *fpos++);
    }
    else if  (myfltsize == 8) {
        dpos = (double*)outbuf;
        for (i = 0; i < nsamples; ++i)
            *bufferpos++ = (short)(32767.0 * *dpos++);
    }

What used to be done with one BlockMove() command (a MacOS call -- likely
very optimized) is now done with my for loop.

Any suggestions for improvement?

Thanks.

Anthony

++ Although it just occurred to me that I am comparing an unoptimized Cs5
build with a fully optimized Cs4 build ...

On 5/17/05 2:08 PM, Anthony Kozar  etched in
stone:

> I am worried that if I write this code myself with all of the conversions from
> float/double to short that it will not be very fast (I don't know any
> optimizing tricks).  (I suppose that I could look to see what Csound did in
> the past).



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> specifying -s to the library and was expecting 32767.0 to be 0 dB (because
> that is what it is in the orchestra).

Actually, 0 dB can be set with 0dbfs in the orchestra, although the default
setting is 32768 for compatibility with existing orchestras. So, the output
is divided by e0dbfs to make the amplitude level predictable (that is, always
+/- 1.0).

>     else if  (myfltsize == 8) {
>         dpos = (double*)outbuf;
>         for (i = 0; i < nsamples; ++i)
>             *bufferpos++ = (short)(32767.0 * *dpos++);
>     }
 >
> Any suggestions for improvement?

I do not think this particular operation can be done significantly faster,
in fact, in rtalsa.c I use this - obviously slower but more accurate - code
to convert from 32 bit floats to 16 bit integers with dithering and clipping
(as that is not done by Csound).

static void float_to_short(int nSmps, float *inBuf, int16_t *outBuf,
                            int *seed)
{
     float tmp_f;
     int   tmp_i;
     while (nSmps--) {
       (*seed) = (((*seed) * 15625) + 1) & 0xFFFF;
       tmp_f = (float) ((*seed) - 0x8000) * (1.0f / (float) 0x10000);
       tmp_f += *(inBuf++) * (float) 0x8000;
       tmp_i = (int) (tmp_f + (tmp_f < 0.0f ? -0.5f : 0.5f));
       if (tmp_i < -0x8000) tmp_i = -0x8000;
       if (tmp_i > 0x7FFF) tmp_i = 0x7FFF;
       *(outBuf++) = (int16_t) tmp_i;
     }
}

However, it is not sure if the format conversion alone is responsible for the
difference (even though it does add some overhead), and it had to be done by
the Csound engine earlier, so it was just moved to a different place.
There are many changes in Csound5 for modularization and allowing for multiple
instances in the same address space that all add some amount of extra CPU usage.
Code compiled as a shared library also runs slower (depending on platform) than
a simple static executable.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> This is almost definitely the problem!  The Cs4 code assumed that outBuf and
> inBuf had the format specified on the commandline (in this case, almost
> always AE_SHORT).  Why is there a sampleFormat member in the csRtAudioParams
> struct if Csound always sends MYFLTs?  Wouldn't it make more sense to have a
> single piece of code (in Csound) for doing the type conversions so that each
> implementor of a set of RT audio callbacks does not have to reimplement this
> same code?

Csound5 was originally intended to be limited to use PortAudio only, the
feature of being able to override rtplay etc. with user defined callback
functions was added later. PortAudio can convert from floats to any format
supported by the audio hardware, with clipping and dithering (probably better
implemented than could be in Csound), so none of these are done by Csound.
Also, some newer interfaces (like JACK) are limited to floats only and assume
a range of +/- 1.0.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Another reason why format conversions are not done by Csound is that
for sound file I/O the libsndfile library is used, that can also convert
from/to floats (with clipping and possibly dithering), and also expects
a signal with a 0 dB level of 1.0. This allowed a very simple implementation
of spoutsf() that does no processing of audio data other than buffering
and range translation from e0dbfs to 1.0.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK.  I was just wondering what the deal was since these were things Csound
used to do.  I am OK with leaving things as they are.  And I would have used
PortAudio for MacOS 9 if that had seemed feasible.

Are we still just using PortAudio v19?  Or is there a module now for v18?  I
thought I saw something about a rtpa-old.c module or something ...

Anthony

On 5/17/05 5:32 PM, Istvan Varga  etched in stone:

> Csound5 was originally intended to be limited to use PortAudio only, the
> feature of being able to override rtplay etc. with user defined callback
> functions was added later. PortAudio can convert from floats to any format
> supported by the audio hardware, with clipping and dithering (probably better
> implemented than could be in Csound), so none of these are done by Csound.
> Also, some newer interfaces (like JACK) are limited to floats only and assume
> a range of +/- 1.0.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

rtpa_new.c is Istvan's portaudio blocking code, which only really works
with Linux (portaudio has not implemented blocking anywhere else).

rtpa.c & pa_blocking.c is the code that John ffitch, Michael Gogins and
myself have worked on to use the portaudio callback model with
the blocking implemented using locks.

I suppose v.18 could be used with Istvan's plugin model, but I'd say it's
too much trouble and waste of time.

Better implement platform-specific plugins as you are doing.

Victor

At 00:59 18/05/2005, you wrote:
>OK.  I was just wondering what the deal was since these were things Csound
>used to do.  I am OK with leaving things as they are.  And I would have used
>PortAudio for MacOS 9 if that had seemed feasible.
>
>Are we still just using PortAudio v19?  Or is there a module now for v18?  I
>thought I saw something about a rtpa-old.c module or something ...
>
>Anthony
>
>On 5/17/05 5:32 PM, Istvan Varga  etched in stone:
>
> > Csound5 was originally intended to be limited to use PortAudio only, the
> > feature of being able to override rtplay etc. with user defined callback
> > functions was added later. PortAudio can convert from floats to any format
> > supported by the audio hardware, with clipping and dithering (probably 
> better
> > implemented than could be in Csound), so none of these are done by Csound.
> > Also, some newer interfaces (like JACK) are limited to floats only and 
> assume
> > a range of +/- 1.0.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That sounds like the best advice.  Thanks for the information!

Anthony

BTW, I am getting pretty comparable performance with the "new" code compared
to the Cs4 code.  Sometimes it is a little bit worse, other times a little
bit better.  It depends on the piece.  With a little more tweaking, I think
that it will be all set ...

On 5/18/05 4:15 AM, Victor Lazzarini  etched in
stone:

> Better implement platform-specific plugins as you are doing.



-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> BTW, I am getting pretty comparable performance with the "new" code compared
> to the Cs4 code.  Sometimes it is a little bit worse, other times a little
> bit better.  It depends on the piece.  With a little more tweaking, I think
> that it will be all set ...

You can also reduce the CPU usage by a few percents (depending on the
actual orchestra code) with the --expression-opt command line option.
For example, trapped.csd renders in 11.54 seconds on my machine with
an optimized build of Csound5 if not using --expression-opt, and in 10.86
seconds if the option is enabled.


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net