There is an alternative in the form of the rtaudio library by Gary Scavone,
which is widely cross-platform and used in Perry Cook's STK. But it doesn't
have the ASIO thunking mechanism, as far as I know, so wouldn't ever work
for ASIO on MinGW.

rtaudio can be used in the form of one or two source files that one
includes in one's projects, so it would be easier to build Csound with it.

I prefer to get PortAudio with ASIO working for MinGW if possible, since
that would make Csound5 a killer live performer on Windows, but if that's
too hard, I'd certainly be willing to switch to rtaudio with which
presumably DirectX would give 20-35 ms latency on Windows and excellent
latency on other platforms.

Alternatively, we could switch back to PortAudio v18 and handle I/O with
callbacks; the performKsmps API would simplfy that change.

Original Message:
-----------------
From: Anthony Kozar anthony.kozar@utoledo.edu
Date: Fri, 14 May 2004 02:34:20 -0400
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4695] Re: PortAudio


I have been wondering about this myself.  v19 has had very poor (or
non-existent) support for several platforms/audio drivers, so far.
(Although this may be improving ?)

I haven't tried either v18 or v19 primarily because Csound5 is supposed to
use v19 and that version does not work on MacOS (9) yet.  So I don't pretend
to speak authoritatively, but it is beginning to look to me that unless we
decide to complete PortAudio v19 ourselves, Csound5 will likely be delayed
for some platforms.  (Or at least real-time support will be).

Can anyone here who watches the PortAudio mailing list gauge how quickly
progress is being made?
 
Anthony Kozar
anthony.kozar@utoledo.edu


On 5/14/04 1:34 AM, John ffitch etched in stone:

> On Thu, 13 May 2004, stevenyi wrote:
> 
>> Hi All,
>> 
>> In regards to the general issues with PortAudio all around, I'm curious
>> why we're using v19 versus v18-patch (I've forgotten why now).
>> 
>> Thanks, steven
> 
> I think it was because we understood that v19 was the future and it was
> not worth the time to design/build for what would be an out-of-date API by
> the time we were done.  Against that I did have a "working" PAv18 system,
> but it was not very nice, and I never tried to push it hard.
> 
> I still think that v19 is the correct decision; it is takig longer than I
> hoped, but I still believe in it.
> 
> ==John ff
> 


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

Portaudio is supposed to support ALSA and that is indeed one of its 
attractions.  No idea about Jack -- never used it.
==John ff

Portaudio v19 does have a pa_jack directory
 * JACK Implementation by Joshua Haberman
 *
 * Copyright (c) 2002 Joshua Haberman 

No idea what state it is in; I would be willing to try if using jack is 
easy.  I do knowe that the scons build has a useJack option but I have 
just never used it.

==John 

Greetings:

  As I read this discussion a question comes naturally to my 
Linux-biased mind: Will Csound5 support JACK and/or ALSA ? I realize 
Portaudio will work with the JACK audio server, but I don't know how or 
to what extent. Currently the audio I/O of JACK-aware applications can 
be easily routed between such apps, and of course the ALSA sequencer API 
supports a similar utility for MIDI. It would be a very retrograde 
decision to continue the now-deprecated OSS/Free API for Linux, but 
perhaps I'm off-base. If so, perhaps one of the developers could tell me 
what is the group's intent regarding JACK/ALSA ?

Best regards,

dp


gogins@pipeline.com wrote:

>There is an alternative in the form of the rtaudio library by Gary Scavone,
>which is widely cross-platform and used in Perry Cook's STK. But it doesn't
>have the ASIO thunking mechanism, as far as I know, so wouldn't ever work
>for ASIO on MinGW.
>
>rtaudio can be used in the form of one or two source files that one
>includes in one's projects, so it would be easier to build Csound with it.
>
>I prefer to get PortAudio with ASIO working for MinGW if possible, since
>that would make Csound5 a killer live performer on Windows, but if that's
>too hard, I'd certainly be willing to switch to rtaudio with which
>presumably DirectX would give 20-35 ms latency on Windows and excellent
>latency on other platforms.
>
>Alternatively, we could switch back to PortAudio v18 and handle I/O with
>callbacks; the performKsmps API would simplfy that change.
>
>  
>

John ffitch wrote:

>Portaudio is supposed to support ALSA and that is indeed one of its 
>attractions.  No idea about Jack -- never used it.
>==John ff
>  
>
Thanks for the info, John.

I would strongly urge Csound5 developers to consider JACK:

    http://jackit.sourceforge.net/

 From the JACK home:

  "JACK is a low-latency audio server, written for POSIX conformant 
operating systems such as GNU/Linux and Apple's OS X. It can connect a 
number of different applications to an audio device, as well as allowing 
them to share audio between themselves. Its clients can run in their own 
processes (ie. as normal applications), or can they can run within the 
JACK server (ie. as a "plugin")."

  "JACK was designed from the ground up for professional audio work, and 
its design focuses on two key areas: synchronous execution of all 
clients, and low latency operation."

JACK-awareness is becoming de rigeur for new Linux audio applications, 
it would be wonderful to see it adopted for Csound5. I know that 
Portaudio "supports JACK" but I don't know how or to what extent. At 
this time Csound5 does not appear as a JACK client. JACK also provides a 
transport control for JACK-aware apps, making possible synchronization 
of all apps via a designated master transport control.

Support for the ALSA sequencer API would also be most welcome. It would 
lend the same kind of connectivity to MIDI as found in JACK for audio. 
There is also a rumored MIDI API for JACK on the horizon that might 
provide sample-accurate synchronization between MIDI and audio streams, 
but I suspect it may not be appropriate for inclusion with Csound5 at 
this time.

However, I do realize that all this incorporation would require work 
time that may not be available to developers, so please don't read this 
message as any sort of demand. It would just be very nice to see 
ALSA/JACK fully supported in Csound.

Best regards,

dp

I built portaudio with jack a while ago and never came up with jack as a
device option in the list of devices when csound ran.  I noticed
yesterday that SFront (MPEG-4 SAOL Compiler) uses PortAudio and supports
ASIO, WMME, DirectX, CoreAudio, Alsa, Jack, etc.  As v19 doesn't have
CoreAudio support last I checked, I'm assuming SFront is using
v18-patch.  I think I'll go look at those sources to see how that was
done, as it appeared it was able to support more than one driver model
and has blocking IO.  

BTW: Gabriel, what version of PortAudio are you using with CsoundAV? 
And you are able to select multiple driver models, yes?

steven


On Fri, 2004-05-14 at 04:59, John ffitch wrote:
> Portaudio v19 does have a pa_jack directory
>  * JACK Implementation by Joshua Haberman
>  *
>  * Copyright (c) 2002 Joshua Haberman 
> 
> No idea what state it is in; I would be willing to try if using jack is 
> easy.  I do knowe that the scons build has a useJack option but I have 
> just never used it.
> 
> ==John 
> 
> 

A problem with Jack so far is that it does not build; looks like it
depends on portaudiov18 but we are using v19
==John ffitch
 gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../config -I../.. -I../.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -I../../config -I../.. -I../.. -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -g -O2 -MT portaudio_driver.lo -MD -MP -MF .deps/portaudio_driver.Tpo -c portaudio_driver.c  -fPIC -DPIC -o .libs/portaudio_driver.o
In file included from portaudio_driver.c:41:
portaudio_driver.h:57: parse error before `PortAudioStream'
portaudio_driver.h:57: warning: no semicolon at end of struct or union
portaudio_driver.h:59: warning: type defaults to `int' in declaration of `portaudio_driver_t'
portaudio_driver.h:59: warning: data definition has no type or storage class
portaudio_driver.c:47: parse error before `PaTimestamp'
portaudio_driver.c: In function `paCallback':
portaudio_driver.c:49: `driver' undeclared (first use in this function)
portaudio_driver.c:49: (Each undeclared identifier is reported only once
portaudio_driver.c:49: for each function it appears in.)
portaudio_driver.c:49: parse error before `)'
portaudio_driver.c:51: `inputBuffer' undeclared (first use in this function)
portaudio_driver.c:52: `outputBuffer' undeclared (first use in this function)
portaudio_driver.c:54: `framesPerBuffer' undeclared (first use in this function)
portaudio_driver.c:55: warning: control reaches end of non-void function
portaudio_driver.c: At top level:
portaudio_driver.c:58: parse error before `*'
portaudio_driver.c: In function `portaudio_driver_attach':
portaudio_driver.c:65: `driver' undeclared (first use in this function)
portaudio_driver.c:65: `engine' undeclared (first use in this function)
etc etc etc etc etc