I'm afraid that, in Portaudio V.19, a blocking mechanism is not 
available for all host apis yet (only WinMME, introduced very recently). 
I suggest to wait a more stable definition of v.19 before using the 
blocking API.
I remember that, for realtime-controlled performances, the callback 
mechanism is highly preferred to the blocking one, due of the huge 
differences in latency delay, especially with professional audio 
interfaces. THe authors of Portaudio tell that the blocking mechanism 
should be used only for small, unpretentious sample application that 
shouldn't require too much programming effort.
There are several ways to make Csound to handle the Portaudio callback 
mechanism, in CsoundAV I chosen the one that allowed the minimum 
latency. This requires to submit CsoundAV to some constraints, i.e. the 
ksmps value also sets the number of frames of the audio buffer (that can 
also be an integer multiple of ksmps). No constraints are obviously 
present for deferred-time processing.

To implement a callback mechanism the rtaudio.c file isn't useful 
anymore, since it is convenient to write the code from scratch...

Gabriel

jpff@codemist.co.uk wrote:
> I tried to rebuild csound5 this morning and it is bust.  In particular
> pablio.c has a large number of hanging references.  I was surprised to
> find it was building this code at all as I was aware that it was not
> working.
> 
> I have two questions:
> a) Does anyone understand portaudio v19 in order to write a version of
> rtaudio?  I have a strong preference for a direct (rather than
> callback) implementation, based on experience with different
> platforms.
> b) How should the configuration be changed to not build this broken
> code?  I no longer have any understanding of the configuration code.
> 
> ==John ffitch
> 
> 


-- 
Gabriel Maldonado
http://csounds.com/maldonado
--