I have requested feedback on this situation and not received any. If I don't
hear anything from anyone, especially John ffitch, I will proceed as I think
best and change the way Csound writes audio and soundfiles.

I have done some further investigation of the possibilities for getting
low-latency PortAudio on Windows with mingw using ASIO.

As others have noted, the PortAudio blocking API has been implemented only
for Windows Multimedia Extensions, not for either DirectX or ASIO.

The options as I see them are to finish the PortAudio blocking API, or to
run the Csound performance loop from the PortAudio callback.

The former would require further understanding of the PortAudio design and
also of ASIO. Basically, there would be two monitors, one for the blocking
write and one for the callback. The blocking write would be called, it would
wait on the blocking write monitor, then write Csound audio to a buffer,
then notify the callback monitor. When the callback was called, it would
wait until the callback monitor was notified, then transfer the data to the
PortAudio buffer, then notify the blocking write monitor. I know from
experience that there is no significant OS overhead from doing things this
way.

Running Csound from the PortAudio callback would however be simpler. The
callback would be written to call performKsmps and then transfer data
directly from spout to the PortAudio buffer. The main Csound thread would
wait on a thread monitor that would be notified when performKsmps indicates
that performance has finished. The only drawback to this scheme is that
Csound's intermediate audio buffer would be bypassed - no spoutsf call.

Actually, I would like to get rid of the intermediate audio buffer
altogether, as it serves no purpose now that I can see. The libraries that
we are now using have their own internal buffers that do the same job.

There would also be the possibility of enabling Csound to write both to
PortAudio and to a soundfile at the same time, since all audio formatting is
now done in the libraries. This would involve changes in the command-line
flags and parsing.

On 8/3/04 11:12 PM, Michael Gogins etched in stone:

> I have requested feedback on this situation and not received any. If I don't
> hear anything from anyone, especially John ffitch, I will proceed as I think
> best and change the way Csound writes audio and soundfiles.

Sorry, I haven't looked at the code yet (and I should have gone to bed hours
ago and thus may not be thinking straight), but two thoughts come to mind.

1.  rtmacintosh.c, rtcoreaudio.c, rtlinux.c, rtwin32.c, etc. all implemented
the same interface, correct ?  If that interface hasn't changed in CS 5 for
rtpa.c, then couldn't we just continue allow building with the old
implementations for those who want them until these issues with PA are
resolved ?

> The options as I see them are to finish the PortAudio blocking API, or to
> run the Csound performance loop from the PortAudio callback.

2.  Audio callbacks on MacOS 9 are interrupts during which there are severe
limitations such as no allocating or deallocating of memory.  I don't know
how things are implemented exactly in Mac Csound right now, but all audio on
MacOS 9, I thought, is via a callback anyways.  (But I am guessing that the
performance takes place out of the callback and is buffered by Csound for
relaying by the callback).

*shrug* 

I probably don't understand this well enough yet ....

Anthony

I'm not sure but I think I remember someone mentioning that portaudio 
for OS X with Core Audio only implemented callback and not blocking. Can 
anyone confirm?
Andrés