I've examined the realtime audio code, and Victor's contributions, and I 
have some questions for John ffitch, Victor Lazzarini, and whoever.

What prevents the PortAudio buffer size from always on every platform being 
equal to the size of spin and spout? i.e. sizeof(float) * nchnls * ksmps.

If this is done there is no need for an intermediate buffer -- spin and 
spout can be copied directly from, and to, the PortAudio callback buffer. -b 
and -B will become meaningless and can be dropped.

Am I missing something here?


----- Original Message ----- 
From: "Art Hunkins" 
To: 
Cc: 
Sent: Saturday, January 08, 2005 4:19 PM
Subject: Re: [Csnd] ASIO4ALL


> Hi, Victor,
>
> Thanks; I stand corrected.
>
> I gather the current debate, then, centers on whether or not we can come 
> up
> with a common set of sources to build Csound5 on all (three) platforms. 
> The
> stumbling blocks seem to be realtime audio and MIDI (and maybe a little
> FLTK).
>
> I gather also that you think it OK for the platforms to diverge where
> necessary - perhaps with the caveat that the user interface remains 
> common.
> Is this fair to say?
>
> Art Hunkins
>
> ----- Original Message -----
> From: "Victor Lazzarini" 
> To: "Art Hunkins" 
> Sent: Saturday, January 08, 2005 3:17 PM
> Subject: Re: [Csnd] ASIO4ALL
>
>
>> That'll depend on the portaudio.dll that you use, not
>> on csound5. As you know, I have built and run csound5
>> with support for all window audio APIs. Anyone could do
>> the same. It'll still be canonical csound.
>>
>> Victor
>>
>> >
>> >I gather that CS5 may still be pretty much limited to ASIO
>> > drivers for a while - at least "canonical" will. Or am I
>> > mistaken?)
>> >
>> > Art Hunkins
>> >
>> > --
>> > Send bugs reports to csound-bugs@cs.bath.ac.uk
>> >               (or to
>> > http://www.cs.bath.ac.uk/cgi-bin/csound ) To unsubscribe,
>> > send email to csound-unsubscribe@lists.bath.ac.uk
>
> -- 
> Send bugs reports to csound-bugs@cs.bath.ac.uk
>              (or to http://www.cs.bath.ac.uk/cgi-bin/csound )
> To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk
> 

Hi All,

I've converted the Docbook Manual from SGML to XML and modified the 
Makefile.  As it's a bit of a change, I thought I'd see if others can 
compile it first as well as get some feedback on it before replacing the 
SGML manual. I've put up a zip at:

http://www.kunstmusik.com/csoundManual.zip

With this zip, you'll need xsltproc installed compile to HTML and FOP 
installed to produce a PDF. 

For Windows, xsltproc can be found in Cygwin, or standalone Windows 
binaries at http://www.zlatkovic.com/libxml.en.html (I believe you'll 
need the libxslt and libxml zip's from there).  For Linux, most distro's 
have xsltproc installed.

For FOP, it is available at: http://xml.apache.org/fop .  To get the 
graphics to work, you'll need to also install the Java Advanced Imaging 
API. Information about JAI is available at 
http://xml.apache.org/fop/graphics.html#jai .  (BTW: FOP is written in 
Java so requires a Java Virtual Machine installed; also, if you run FOP, 
I recommend editing the fop.sh file and add "-Xmx384m" to the last line, 
so it reads as such:

$JAVACMD -Xmx384m -classpath "$LOCALCLASSPATH" $FOP_OPTS 
org.apache.fop.apps.Fop "$@"

This increases the max ram the VM can use to 384megs, which you'll need 
for FOP to run as the manual is fairly large)

I've tested this on Cygwin using Cygwin's xsltproc, MinGW using the 
natively compiled xsltrpoc, as well as Linux.  The makefile in the zip 
is set to compile with "make html" and  "make pdf", with the default set 
to just HTML.

Currently, the version in CVS still uses SGML but should be encapsulated 
with respects to the stylesheets; this runs on Linux fine for me and 
produces output identical to the ACRM.  On the other hand, I've gotten 
the XML versions to run on multiple platforms, but the stylesheets are 
not tweaked to be like the ACRM.

If anyone could give this a try and let me know any feedback on how it 
works for you (or doesn't), I'd appreciate it.

Thanks,
steven

One problem is that the ksmps size is based on synthesis needs the
buffer size for rtaudio is based on hardware speeds.  If I remember
correctly, on OSX that just fails.  If -b is set to a sensible ksmps
size then the stuttering is way below feasible.  I think that there
is a need for extra buffering.
  The code I have on the Mac collects data until there is enough for
the buffer.  I got distracted by external deadlines so have not
finished the code.
==John ffitch

On Mon, 10 Jan 2005 jpff@codemist.co.uk wrote:

> One problem is that the ksmps size is based on synthesis needs the
> buffer size for rtaudio is based on hardware speeds.  If I remember
> correctly, on OSX that just fails.  If -b is set to a sensible ksmps
> size then the stuttering is way below feasible.  I think that there
> is a need for extra buffering.
>  The code I have on the Mac collects data until there is enough for
> the buffer.  I got distracted by external deadlines so have not
> finished the code.
> ==John ffitch


if its any use to you, here is what i do with coreaudio. it sounds like 
it might be related.. -m


 	char *_rtCurOutBuf = 0; /* external host's outbuffer passed in 
csoundPerformBuffer() */
 	long _rtCurOutBufSize = 0;
 	long _rtCurOutBufCount = 0;

 	long _rtBufferSize = 0;

 	char *_rtInputBuf = 0;
 	long _rtInputBufSize = 0;
 	long _rtInputBufIndex = 0;

 	void playopen_(int nchanls, int dsize, float sr, int scale) /* 
open for audio output */
 	{
 	if (_rtBufferSize) {
 			if (O.outbufsamps*dsize != _rtBufferSize)
 				die("Input buffer must be the same size as 
Output buffer\n");
 		}
 		else
 			_rtBufferSize = O.outbufsamps*dsize;

 		_rtCurOutBufSize = _rtBufferSize;

 		/* a special case we need to handle 'overlaps' */
 		while (_rtCurOutBufSize < ksmps*nchanls*dsize)
 			_rtCurOutBufSize += _rtBufferSize;

 		_rtCurOutBufCount = 0;
 		_rtCurOutBuf = mmalloc(_rtCurOutBufSize);
 	}

 	/* will sometimes be called more than once if ksmps > -b */
 	void rtplay_(char *outBuf, int nbytes)
 	{
 		memcpy(_rtCurOutBuf+_rtCurOutBufCount, outBuf, nbytes);
 		_rtCurOutBufCount += nbytes;
 	}

 	void recopen_(int nchanls, int dsize, float sr, int scale)
 	{
 		if (_rtBufferSize) {
 			if (O.inbufsamps*dsize != _rtBufferSize)
 				die("Input buffer must be the same size as 
Output buffer\n");
 		}
 		else
 			_rtBufferSize = O.inbufsamps*dsize;

 		_rtInputBuf = mmalloc(_rtBufferSize);
 	}

 	int rtrecord_(char *inBuf, int nbytes)
 	{
 		memcpy(inBuf, _rtInputBuf, nbytes);
 		return nbytes;
 	}

 	void rtclose_(void)
 	{
 		// this is causing a crash
 		if (_rtCurOutBuf) {
 			mfree(_rtCurOutBuf);
 			_rtCurOutBuf = 0;
 		}
 		if (_rtInputBuf) {
 			mfree(_rtInputBuf);
 			_rtInputBuf = 0;
 		}
 	}

In addition to the problems on OS X, as I said last week,
portaudio ASIO is also dependent on the driver implementation;
in certain cases, the buffer sizes are only of certain allowed
values (a certain 'granularity') and have a minimum value.
This seems to cause trouble for audio input, but not for
output.

I think we could re-instate one 'hardware' buffer (-B option);
we could follow portaudio's advice in letting the portaudio buffer
be variable as so to be able use the minimum latency possible,
with the user having control of csound hardware buffer.

Victor

At 07:04 10/01/2005, you wrote:
>One problem is that the ksmps size is based on synthesis needs the
>buffer size for rtaudio is based on hardware speeds.  If I remember
>correctly, on OSX that just fails.  If -b is set to a sensible ksmps
>size then the stuttering is way below feasible.  I think that there
>is a need for extra buffering.
>   The code I have on the Mac collects data until there is enough for
>the buffer.  I got distracted by external deadlines so have not
>finished the code.
>==John ffitch

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