I’ve also seen the problem that the beginning and/or the end of the sound are not played. I don’t know if that’s a PortAudio problem or a problem of the underlying audio drivers. This is yet another reason to start the stream in the beginning of the session, some time before the actual audio signals are to be played back.
According to the PortAudio docs, the blocking API is not supported on all host APIs, it looks like WDM-KS is one of those. I don’t know if this is supported in a more recent development version of PortAudio?
I’d recommend that you write your own callback function. In the beginning, it would only write zeros to the output. As soon as an audio signal is to be played back, this function should write blocks of it to the output.
Once that works, you could use the time attribute to start playback at a fixed delay. This way you will add some latency, but if all goes well, it should reduce the jitter.
If that actually works, you could put in the extra effort to re-write the callback function in C and compile it with CFFI in API/out-of-line mode. This should give you the most reliable performance, since Python wouldn’t be involved at all in the callback.