Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:5648] RE: ASIO full-duplex, update.

Date2005-01-07 16:31
From"gogins@pipeline.com"
Subject[CSOUND-DEV:5648] RE: ASIO full-duplex, update.
I think it only means you have to have the right values for -B, -b, and
ksmps. Why should we expect the old flags to work out of the box with a new
driver?

Original Message:
-----------------
From: Victor Lazzarini Victor.Lazzarini@nuim.ie
Date: Fri, 07 Jan 2005 15:04:11 +0000
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5646] ASIO full-duplex, update.


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  


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Date2005-01-07 16:38
FromVictor Lazzarini
Subject[CSOUND-DEV:5649] RE: ASIO full-duplex, update.
Perhaps there's a better solution: I had a look at

http://www.portaudio.com/docs/proposals/004-CallbackVariableFramesPerBuffer.html

Perhaps we should re-think the code to use the frameCount argument to the
callback and make the callback IO buffers independent of the ksmps value.
However, this has not been implemented on coreaudio, it seems.

The whole trouble is that some of docs are v.18 and the behaviour of v.19 
seems to
be very different.

In any case, I think realtime audio should work regardless of the value of 
ksmps and
nchnls; it shouldn't be the case of having right values for these parameters.

Victor

At 16:31 07/01/2005, you wrote:
>I think it only means you have to have the right values for -B, -b, and
>ksmps. Why should we expect the old flags to work out of the box with a new
>driver?




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