Re: Portaudio, ASIO and Borland Builder 6

ANN: Csound 5.00 Release

Csound 5 has finally arrived, enjoy...

-Victor
==================================================
After what has seemed a very long time (because it was...) we are
releasing csound5.00
   The binary, manuals and source files are on
http://sourceforge.net/projects/csound and look for the csound5 files.
The opportunity has been taken to tidy up the assembly of csound4.23
and earlier files and we are leaving the 4.23 files for a short
while.
   Main message -- everyone should change to csound5.  More robust,
faster, more facilities, more fun, more music.

==John ffitch
------------------------------------------------------------------------
Release Notes for Csound 5.00
-----------------------------

The developers are very pleased to be releasing Csound5, for Linux (32
and 64 bit), Mac OSX and Windows, together with an uptodate manual.

The system can be downloaded from http://sourceforge.net/projects/csound

More details and further information can be found in the
csound-develop mailing list at sourceforge and the main user mailing
list ar csound <at> lists.bath.ac.uk

The changes from version 4.23 are extensive.  The internal structure
of the code has been radically changed, but the language remains
compatible with Csound4, and all old orchestra/scores should run
unchanged.

The main visible change is that we are using a plugin style of
system.  many of the opcodes are now loaded at start-up.  This opens
the way for private opcode libraries, and opcodes released under other
licences than LGPL.

The other major change is a move to the use of external libraries
where possible.  All the internal code for sound files, realtime audio
etc has been replaced.  We are now using libsndfile for audio file
I/O, and one of ALSA, PortAudio, CoreAudio, MME or ASIO for realtime.
MIDI may be handled by PortMIDI as well.  The incorporation of Open
Sound Control facilities uses the liblo library.

A number of opcodes from csoundAV and csoundVST are now part of the
main system.

Another major change is that Csound5 is embeddable in other
programming systems, using an API for information linkage.  We are
including Python, Java and other bindings for the API.  Csound5 can
also have multiple instances and is re-entrant.

In addition there are a number of new opcodes, and of course bug
fixes.  We believe that csound5 is faster than csound4, and we
encourage all users to move to it.

NOTE: IT MAY BE NECESSARY ON SOME PLATFORMS TO HAVE EITHER ENVIRONMENT
VARIABLES OPCODEDIR OR OPCODEDIR64 SET TO POINT TO DIRECTORY WHERE
OPCODES LIVE.  THE RELEASED FILES ARE BELIEVED TO BE SAFE AND CORRECT
IN THIS RESPECT BUT BEWARE!

New features:
------------
Access to multiple ALSA devices
FLTK widgets reworked and synchronised with csoundAV
User defined gens with names (rather than numbers)
--expression-opt command option
Information on time for each phase of csound if required
Command line options to set ID tags in output soundfile
         (title/copyright etc)
Jack available as output device
--sched option now accepts a priority value
-+rtaudio option to select output system
Many new command line options
Utilities to create csd files from orc/score
Tcl/TK frontends (cstclsh and cswish)
Can use looping structures in WAV files as well as AIFF
Increased number of possible input and output audio file formats
named channels
#ifdef in orchestra
removed limitation of only one track in MIDI input files
MIDI output can also be written to a file (this is somewhat limited)
MIDI-style extra time and release (xtratim, linsegr, etc.) is now
         also possible with score notes
string variables (of type S)
automatic conversion of some C-style escape sequences (\n, \r, ASCII
         code in octal \ooo format, etc) in string constants
made internal indexes to orchestra variables 32 bit (was 16 bit in
         Csound 4), allowing for larger and more complex instruments
replaced old PVOC format with PVOC-EX in all related opcodes
SADIR SSDIR and INCDIR can now be a colon separated list of directories

New Opcodes:
-----------
maxk
tab, tabw, and tb0()..tb15()
vst4cs plugin opcodes
pconvolve
ftconv
loris opcodes
Python opcodes
fluid opcodes
chani and chano; chnset and chnget (string indexed)
GEN43
a number of pvs (streaming phase vocoder) opcodes
moogladder
statevar
fofilter
syncgrain
miditempo
event_i
reverbsc (Sean Costello's waveguide reverb)
freeverb
gentune GEN operation
GEN51
GEN52
diskin2
turnoff2
a-rate int() and frac(), and round(), floor(), and ceil()
  << and >> operators
STK (Perry Cook) instruments available from original code
k() function
Mixer opcodes
OSCrecv, OSClisten, OSCsend
loop opcodes
printf, printf_i
string hacking opcodes

Bug Fixes:
---------
Error in tablew fixed
Minor fixed in dcblock
Include files were confused by sections
Improved reading of command line
Fixes in dynamic fgen numbers
gogobel and vibraphone amplitude fix
Arguments to schewhen were wrong
Better checking in bqrez
minor checking in grain
wguide2, wguide1 avoid very low frequencies
wgpluck bug fix
Some error messages corrected and typos fixed
FLsetVal arguments were wrong
outo missed out channel 6
fixed bugs and improved error reporting in ^+ and ^- code.
kread, kdump and a number of other opcodes will take string arguments
         from the score
bug fix in sinc window (gen20)
Added iskip options to moogvcf, vco, bqrez, pareq, tbvcf and rezzy
         values rounded rather than truncated in deltap, comb, and delay
removed spurious initial values from some MIDI opcodes
Joystick was upside down
lpshold and loopseg changed to agree with csoundAV
marimba now allows zero probability of a multiple strike
Added skipinit argument to diskin and soundin
wave-terrain fixes for phase error accumulation (on long notes)
new optional argument to delayr and all deltap opcodes,
           to allow delay taps to read from any of the nested delayr/delayw
           pairs, not just the last
new optional argument to distort1 opcode (defaults to zero),
           to select amplitude scaling mode (0: default, compatible with
           original version; 1: relative to 0dBFS, same as mode 0 if 0dbfs is
           32768; 2: unscaled)
valpass fixed parameter overwriting
Improved accuracy in some filters
Improvements in bowedbar

JPff -- 1 Feb 2006

Files on Sourceforge
====================

Sources:
         Csound5.00_src.tar.gz
         Csound5.00_src.zip
         Csound5.00_OS9_src.smi.bin
         Csound5.00_src_all.tar.gz (including Loris and STK code)
         Csound5.00_src_all.zip (including Loris and STK code)

Manual
         Csound5.00_manual_chm.zip
         Csound5.00_manual_html.zip
         Csound5.00_manual_pdf.zip
         Csound5.00_manual_pdf_A4.zip
         Csound5.00_manual_single_file.zip

OS9:
         Csound5.00_OS9.smi.bin

OSX:
         Csound5.00_OSX10.3.tar.gz
         Csound5.00_OSX10.4.tar.gz

Linux
         Csound5.00_i686.rpm
         Csound5.00_x86_64.rpm
         [Linux for non-root users on X86_64
             Csound5.00_x86_64d.tar.gz
             Csound5.00_x86_64f.tar.gz
         ]

Windows
         Csound5.00_win32.i686.zip
         Csound5.00_win32.exe (with installed)

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

Re: Portaudio, ASIO and Borland Builder 6

  Bruce Wiggins <bruce.wiggins <at> gmail.com> wrote:

> I have tried using the IASIOThiscallResolver, but the problem seems to be
> related to the fact that all the code surrounded by declarations such 
 > as #if MAC are not being ignored as they should be.
> 
> Has anyone got ASIO, Portaudio and Borland builder to work together, and if
> so, how did you do it?

Bruce,
   I have an application that uses ASIO and is compiled with C++Builder V6.
It doesn't use Portaudio, but I don't think this is relevant for your
problem. I looked into the IASIOThiscallResolver routine, but I don't see
those #if MAC that you mention, while I see some #if specifically meant for
the Borland compiler e.g.

#if defined(__BCPLUSPLUS__) || defined(__BORLANDC__)

If you want, I can send you this IASIOThiscallResolver module.

73  Alberto  I2PHD

Re: ANN: Csound 5.00 Release

>>Also if you don't want to install the
>>support libraries (ie. you have them) you can unselect them from
>>the installation.
>
>But what are I supposed to do if *some* of the libraries needed by
>CSound are missing on my system??? but at same time i don't want to
>overwrite my libjack version ? (for example: because i am developing it)

You can get and install them yourself, they are easily available on the
web. As you are a developer, this should not be a problem for you.

>So basically i can not afford to install this package on my system,
>because of this too unsafe behaviour.

That's your decision, but there is no particular problem if you do not
want to install the supportlibs package. This package is there for people
to install it if they want it or need it.

>Best Regards
>
>Stephane Letz
>

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

Re: Portaudio, ASIO and Borland Builder 6

This is basic ASIO SDK usage and is not directly related to PortAudio.

You have to set up and include "asiosys.h" *before* the main ASIO header
is the file is not already included.

This file is shipped with the SDK.

Its content for my x86-32bits builds is:

#ifndef __asiosys__
#define __asiosys__

       #undef MAC
       #undef PPC
       #undef SGI
       #undef SUN
       #undef LINUX
       #undef BEOS

       #define ASIO_LITTLE_ENDIAN 1
       #define ASIO_CPU_X86 1
       #define NATIVE_INT64 0
       #define IEEE754_64FLOAT 1

#endif

You were right when you solved your problem by adding the #define
manually, but you missed this bit I guess... :p

[Fakyrr]

Fwd: Re: Portaudio, ASIO and Borland Builder 6

Problems with MacOS X and PortAudio V18.1

Problems with MacOS X and PortAudio V18.1 - this time without the HTML!

Hi, apologies if this email is a duplicate! - I seem to be having
troubles emailing this list)

I'm developing a simple cross platform speech compression library using
Speex (v 1.0.5 ) and PortAudio (v18.1). It is working perfectly under
Linux and Windows, however I am having problems with the Mac OS X
version. I have three threads running (pthreads for *nix, CreateThread
for Win), one devoted to capturing and compressing audio, one devoted to
decompressing and playing audio, plus another for the actual
application. So yes, I guess I'm using PortAudio for full duplex audio,
but doing so in separate threads. I am capturing at 8000 Hz and using a
data format of short int. I have written a single callback function that
writes to one ring buffer, and reads from another. I imagine that this
callback will be executing in a different thread context depending on
whether it is being called for recording or playback. I am using the
 ringbuffers supplied in the Pablio add-on for PortAudio. My two threads
that look after the recording and playback read and write to these ring
buffers. I then pass information to and from the main application with
 two more ring buffers. As stated earlier, the Linux and Windows versions
of this app are working perfectly. However, when I run it under Mac OS
X, I get the following error output (I have enabled debug output in
 PortAudio).

-----thread context of playback thread------------
Pa_OpenStream(0xf0182e10, -1, 0, 2, 0x0, /* input */
                         1, 1, 2, 0x0, /* output */
                         8000, 160, 0, 0x0, , 0xf0182df0)
-----thread context of record thread-----------
PaOpenStream(0xf0080e10, 0, 1, 2, 0x0, /* input */
                         -1, 0, 2, 0x0, /* output */
                         8000, 160, 0, 0x0, , 0xf0080df0)
Pa_StartStream: PaHost_StartInput returned = 0x0.
Pa_StartStream: PaHost_StartEngine returned = 0x0.
-----thread context of playback thread------------
Pa_StartStream: PaHost_StartOutput returned = 0x0.
PaHost_StartEngine: AudioDeviceAddIOProc primary failed: error =
0x6E6F7065 = 'kAudioHardwareIllegalOperationError'
Pa_StartStream: PaHost_StartEngine returned = 0xFFFFD8F0.

If I ignore the error and try again, I get a Bus Error.

I have a few questions:
1. Should I be using V19 of PortAudio? - I have had a look at the
mailing list, and it seems most discussions are about V19.
2. Is there anything in the description above that appears to be stupid
with regards to using PortAudio? - threading etc.
3. I am using Autoconf and Automake to build the Mac Version, is there
anything wrong with this?
4. Could the author of Configure.in please make a couple of alterations
to the file please? Under Darwin?

Please change: Line 36 from
OTHER_OBJS="pa_mac_core/pa_mac_core.o"
to
OTHER_OBJS="pa_mac_core/pa_mac_core.o pablio/ringbuffer.o"

and line 37 from
LIBS="-framework CoreAudio -lm"
to
LIBS="-framework CoreAudio -framework AudioToolbox -lm"

and finally on line 39 from
SHARED_FLAGS="-framework AudioToolbox -dynamiclib";
to
SHARED_FLAGS="-framework CoreAudio -framework AudioToolbox -dynamiclib";

Kind Regards,
Nick George

Re: Problems with MacOS X and PortAudio V18.1

On Fri, 3 Feb 2006, Nicholas George wrote:

> Hi, apologies if this email is a duplicate! - I seem to be having troubles
> emailing this list)
>
> I'm developing a simple cross platform speech compression library using
> Speex (v 1.0.5) and PortAudio (v18.1). It is working perfectly under
> Linux and Windows, however I am having problems with the Mac OS X
> version. I have three threads running (pthreads for *nix, CreateThread
> for Win), one devoted to capturing and compressing audio, one devoted to
> decompressing and playing audio, plus another for the actual
> application. So yes, I guess I'm using PortAudio for full duplex audio,
> but doing so in separate threads. I am capturing at 8000 Hz and using a
> data format of short int. I have written a single callback function that
> writes to one ring buffer, and reads from another. I imagine that this
> callback will be executing in a different thread context depending on
> whether it is being called for recording or playback. I am using the
> ringbuffers supplied in the Pablio add-on for PortAudio. My two threads
> that look after the recording and playback read and write to these ring
> buffers. I then pass information to and from the main application with
> two more ring buffers. As stated earlier, the Linux and Windows versions
> of this app are working perfectly. However, when I run it under Mac OS
> X, I get the following error output (I have enabled debug output in
> PortAudio).
>
> -----thread context of playback thread------------
> Pa_OpenStream(0xf0182e10, -1, 0, 2, 0x0, /* input */
>                         1, 1, 2, 0x0, /* output */
>                         8000, 160, 0, 0x0, , 0xf0182df0)
> -----thread context of record thread-----------
> PaOpenStream(0xf0080e10, 0, 1, 2, 0x0, /* input */
>                         -1, 0, 2, 0x0, /* output */
>                         8000, 160, 0, 0x0, , 0xf0080df0)
> Pa_StartStream: PaHost_StartInput returned = 0x0.
> Pa_StartStream: PaHost_StartEngine returned = 0x0.
> -----thread context of playback thread------------
> Pa_StartStream: PaHost_StartOutput returned = 0x0.
> PaHost_StartEngine: AudioDeviceAddIOProc primary failed: error =
> 0x6E6F7065 = 'kAudioHardwareIllegalOperationError'
> Pa_StartStream: PaHost_StartEngine returned = 0xFFFFD8F0.
>
> If I ignore the error and try again, I get a Bus Error.

> I have a few questions:
> 1. Should I be using V19 of PortAudio? - I have had a look at the
> mailing list, and it seems most discussions are about V19.

Yes, v19 is the wave of the future. v18 is considered frozen.

I recently rewrote the v19 code and it's been working well for everyone 
who has cared to comment. (There is a pending patch for intel macs and 
someone has commented that the proformance is worse for v19 than v18, but 
I plan to address both these issues at some point in the not terribly 
distant future.)

But I don't think that upgrading to v19 is the magic bullet that will 
solve your problem.....

> 2. Is there anything in the description above that appears to be stupid
> with regards to using PortAudio? - threading etc.

Yes. In your description, you said you used seperate threads for input and 
output. I presume this means you have two streams open and use seperate 
callbacks for input and output. That's not the way to do full duplex. 
Instead, you should use a single callback for doing both input and output. 
I would venture to guess that this is your problem, and it may be causing 
subtle problems on other platforms as well.

> 3. I am using Autoconf and Automake to build the Mac Version, is there
> anything wrong with this?

probably not if it compiles. v19 is actively developed this way, although 
I am not sure how well the process will work with intel macs.

> 4. Could the author of Configure.in please make a couple of alterations
> to the file please? Under Darwin?
>
> Please change: Line 36 from
> OTHER_OBJS="pa_mac_core/pa_mac_core.o"
> to
> OTHER_OBJS="pa_mac_core/pa_mac_core.o pablio/ringbuffer.o"
>
> and line 37 from
> LIBS="-framework CoreAudio -lm"
> to
> LIBS="-framework CoreAudio -framework AudioToolbox -lm"
>
> and finally on line 39 from
> SHARED_FLAGS="-framework AudioToolbox -dynamiclib";
> to
> SHARED_FLAGS="-framework CoreAudio -framework AudioToolbox -dynamiclib";

With v18 being frozen, I think the preference is not to change it. 
Hopefully if anyone has trouble compiling in the future, they will find 
this post.

 	bjorn

-------------
Bjorn Roche
Check out my CD Mastering Software
for Mac OS X : http://www.xowave.com

Some newbie questions

Hi all.

I'm a new PortAudio user, having just 'borrowed' the C# binding of 
PortAudio from FlexRadio for my open source music composer. I'm fairly 
impressed with what I've seen, but I have a few questions on the basic 
capabilities of PortAudio. My choice of PortAudio is by no means permanent 
because I'm still not sure whether it will do the job. I hope someone here 
can answer these and bring me a step closer to cross-platform, low-latency 
3D sound.

1) Will ASIO device options become available with the installation of 
ASIO4all or some other Windows ASIO driver, or is this only available with 
a high-end soundcard installed?
2) Does PortAudio do more than 2 channels in Windows? I have a four channel 
(SBLive) and a six channel (crappy on-board) soundcard, but both are 
detected as two channels only.
3) How hard is it generally to get an application written with PortAudio 
going under a different OS - leaving all other considerations aside. In my 
case I'm linking to a DLL with a C# binding. I can do C# under Linux, but 
what about DLLs?
4) The API docs advise against setting one's own block size. I would really 
prefer to be able to do so if possible (or better yet enumerate some 
suggested sizes from the API having chosen my desired latency). How much 
does this affect latency/reliability in practise, and are there any other 
caveats?
5) What is the recommended sample format? Is there a performance hit with 
using certain sample formats? Is it possible to enumerate supported sample 
formats?

Thanks very much to anyone who can answer these for me. If anyone's 
interested, you can check out the reason I'm doing this to myself at 
http://sourceforge.net/projects/buzz-like

Have a nice day,
Aaron.