Thanks for your valuable and instructive information.

I think we really need to see if ASIO PortAudio works on the Mac. 

If it doesn't work out of the box, I don't see buffer sizes as a problem.
We can implement an intermediate buffer and let it fill up in the
pa_blocking.c file.

Original Message:
-----------------
From: Victor Lazzarini victor.lazzarini@may.ie
Date: Thu, 30 Dec 2004 10:25:13 +0100
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5601] cs5 OS X audio issues (a long one)



I have had a look at the cs5 audio question on
OS X (with a 20/dec snapshot build) and I've nailed
the problem.

It seems that the buffer used for the callback, because it
is dependent on ksmps, is often too
small. I ran a test with kr set to 10 and ksmps 4410
and I got uninterrupted audio.

Looking at the implementation, it is clear that portaudio
does not have the same behaviour 
across systems. On Windows, Michael Gogins'
code works well because (I presume) there is some
intermediary buffering done by portaudio, so that
if you change the suggested latency, you can 
eliminate dropouts; this seems to be the norm
for MME/WDM. With ASIO, I suspect the suggested
latency does not have any effect, as the buffer size is set
by the driver, not the client.

Now on OS X, portaudio behaves differently.
With coreaudio, it does not seem to have intermediary
buffering, a callback seems to be
invoked for every HAL callback. So with a 
buffer of say, 100 samples, cosund really 
has trouble keeping up and all we get is a
stream interrupted by lots of droupouts.

Perhaps, with ASIO instead of CoreAudio,
we will have some intermediary buffering,
but at the moment I can't test that, because
I don't have an ASIO soundcard handy (I'm
supposed to be on holidays...) or the means
to get the SDK.

This means that we will have to implement the
coreaudio portaudio IO differently to the windows
one. Now this is starting to defeat the purpose
of using portaudio, because we wil end up with
three different sets of audio IO functions, as the
linux implementation is again different.

That makes you wonder whether portaudio makes
promises it cannot live up to. If the library behaviour
changes, the portability goes out of the window.
It doesn't matter that the thing has an interface
that looks the same for all systems, if it does not
work the same way.

Another big problem that we will have to face up
to is the full-duplex issue with ASIO (and with
CoreAudio, as well). These APIs do not let you
open output and input separately, so with the
way things are, csound will only open for input
or for output. With coreaudio, it is possible that
some drivers will let you open them twice, but
I have not yet found one that does it. 

This is not a major problem, all we need to do it is
to open it once only, full-duplex. But the problem
is that, again, we will have to provide yet another
different implementation for something that was
supposed to be uniform.

Well, anyway that's it. At least we seem to know
now why the audio output was so bad on OS X.

All the best,

Victor
















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