I was finally able to test my full-duplex code with ASIO on
windows, and this is what I found out.

1. I had to do some changes to rtpa.c because when recopen_() is
called, rtout_dev is still set to 1024 (default), so it cannot be compared
to rtin_dev. Funny thing, because on OSX rtout_dev is set to the right
device value (!?).

2. With this working, the device opened and I got audio in, but with very
low quality, full of dropouts. Audio out was always fine, if synthesised.

3. Noticed that the input signal was transposed an octave down; so
it was a channel mismatch. After some head scratching, realised that
although the global nchnls was one, the input was being open with 2 channels.

4. The code to set the device nchnls was OK, but it seems that PortAudio
ASIO refuses to open the device in mono! I'm not sure now whether this
is with all soundcards; but it looks like ASIO always opens the device
at least in stereo. However, PortAudio should take care of this, by discarding
the second channel if in mono, which it does not seem to do!
That's how I implemented it in the SndObj library (but it's been a while, so
I forgot the details).

5. So why is it that output always works, mono or stereo? Well, I assume
that portaudio just takes whatever output csound has synthesised and
sends it in; since csound has not generated, say, only one channel, it
basically zeros the other channel. But the device is open in stereo.

6. The coreaudio implementation works because coreaudio actually lets
you open the device in mono.

7. OK, so what works? Well, it seems that if you have a stereo orchestra,
with ksmps set to 441, you can get sound in and out with very low latency.
But, with a smaller ksmps it does seem to struggle. But it does not seem to
be a size issue, because with ksmps=1, it works perfectly.
It seems to be a granularity problem: the intermediary buffer set-up by
portaudio has to be a multiple of a certain size, but if that does not agree
with the ksmps value, then we have dropouts, probably because the buffer
is not completely filled or it discards some samples.
However, with all this, ouput seems to work not matter what! I can get the
most horrible audio in and at the same time produce a perfect sinusoid
by synthesis.

8. Another problem seems to be that csound is crashing at exit. I have to
investigate that.

9. Conclusion: it seems that we will have to again provide a proprietary
solution for ASIO; and this using a library that was supposed to provide
an unified interface to all devices in different platforms!

Suggestions are *very* welcome,

all the best














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

More findings...

In relation to buffersizes and ksmps, I have now found that:

(a) if ksmps < ASIO_buffersize*channels
      the only way of not having dropouts is to set ksmps=1

(b) if ksmps > ASIO_buffersize*channels
      it seems to work OK.

The ASIO_buffersize is given by the driver. In the case of the
soundcard I'm testing (Delta Quattro), it is set by the latency
category in the ASIO control panel.

I realised it can be obtained from the 'defaultLowInputLatency' value
given by portaudio. So we might be able to provide some intermediary
buffering to make pabs.ActualBuffer comply with the minimum size.

According to the portaudio docs on ASIO, this should not be needed,
as portAudio would provide a callback buffer adaptation whatever buffersize
the user required. This only seems to work with audio output.

We'll also have to deal with the mono input problem, perhaps we can combine
the solutions for these two issues.



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