I look forward to checking it out. What does it need to be the "right"
library?

Original Message:
-----------------
From:  jpff@codemist.co.uk
Date: Sun,  4 Jan 2004 18:49:23 +0000
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3891] Sound libraries


In the spirit of moving ahead I have been investigating the use of
libsndfile as a library for sound files.  I have the output section
working and the code is a little simpler.  I am still not convinced
it is the "right" library, but it certainly does remove a lot of
suspect code.  Some issues still need to be resolved.
  I have added a flag _SNDFILE_ to use this instead.  If this seems OK
I will remove all this and simplify the code.  Needs some changes to
the configure stuff as well if accepted.
==John ffitch


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

"right" library is the one that cause the least modifications to the
system and provides all the facilities required.  At present
libsndfile does not provide a way of reading loop points as far as I
can tell, and I need a facility to add additional chunks.  I am in
contact with Erik de Castro Lopo about some of this.

I have created output from csound5 using both the old code and
libsndfile, but it needs more testing for other formats.  I am very
uncertain about the normalisation of floating formats in libsndfile,
and I need either to allocate a half day to it, or to get others who
understand the issues to test it.

I have started the reading of sound files as well; so far OK, but not
tested.

I have checked the new file into CVS (InOut/libsnd.c) but the normal
Makefile does not know about this, nor sets _SNDFILE_

==John ffitch

On 1/4/04 3:21 PM, jpff@codemist.co.uk etched in stone:

> "right" library is the one that cause the least modifications to the
> system and provides all the facilities required.

Including working on all necessary platforms I would assume.

A couple of days ago, I was working on porting to Mac OS 9 a linux audio
program which happened to use libsndfile.  I downloaded version 1.0.5 from
Erik's web site.  There seems to have been support for OS 9 in the past but
the Mac read me was written for version 0.0.16.  Much has changed since then
in the library including switching to using GNU autoconfig, etc.  The Mac
config.h file was seriously out of date.

I did manage to get the library to compile after about half a dozen changes
to the source, but I have no idea if it works yet since there is an issue in
linking to the library I built.

I should be able to resolve this issue, but there is still a fairly heavy
use of non-ANSI-C Unix calls in the library from what I can tell.  These are
"available" with CodeWarrior on Mac OS 9 but some of them may not behave
correctly.  Again, testing will be necessary, but most of the issues can
_probably_ be resolved if libsndfile is chosen.


To help with the process of selecting a library, I have compiled below a
survey of possible choices that I am aware of.

libsndfile, by Erik de Castro Lopo, has these features:

    *  supports a very impressive list of sound file formats and encodings
    *  claims that others should be easy to implement
    *  very robust handling of endian issues
    *  on-the-fly conversion of samples to several data-types
    *  can automatically write PEAK chunks to AIFF and Wave files
    *  seems to have commands to set float normalization behavior
    *  can easily or automatically update file header as data is written

libsndfile limitations:

    -  difficult to write other custom chunks/binary data ?


SndLib, from Bill Schottstaedt and used in Snd and Common Lisp Music has the
following features:

    *  basic read and write of NeXT, AIFF, Wave, Ircam, and Raw sound files
    *  "low level" API for manipulating file headers and read/write binary
       arrays
    *  basic support for audio hardware (playback and record)
    *  has a nice set of functions for "endian-aware" data-type conversions
    *  interfaces for C, Lisp, Scheme, Ruby, and Forth

SndLib limitations:

    -  choice of sample data representation seems to be statically
       determined at compile time ??
    -  audio support and other features would be "extra baggage" ?


The "Audio File Library," developed by Michael Pruett, seems primarily aimed
at the Unix platform.  It supports NeXT, AIFF, Wave, and Ircam (others?)
with several encodings.  Lack of any information regarding compiling on
Windows, Mac, BeOS, etc, plus an impression that the library is still rather
young, make me think that this may not be a good choice.

PortSoundFile, a part of the PortMusic project directed by Ross Bencina and
Phil Burk, would be nice from the perspective of being the companion to
PortAudio and PortMidi.  However, it does not seem to actually exist yet
(??).

John ff. mentioned Dobson's PortSF.  Is this the same as PortSoundFile which
is part of PortMusic?  No other links to a "PortSF" showed up in a google
search.

Apple's QuickTime is very well tested and fully functional but obviously
won't work except for the MacOS and Windows.


Summary of Operating System support:

            Linux Unix  Sun   Irix  NeXT  Win   DOS   Mac9  MacX  BeOS

libsndfile  yes   yes   yes?  yes?  yes?  yes   no?   yes?  yes   no?
sndlib      yes   yes   yes   yes   ???   yes   no?   yes   yes   no
Audio File  yes   yes   yes   yes   yes?  no    no    no    yes?  no?
PortSF      yes   yes?  yes?  yes?  ???   yes   no?   no?   yes   ???
QuickTime   no    no    no    no    no    yes   no    yes   yes   no


Summary of Licenses:

libsndfile        LGPL
sndlib            BSD-style
Audio File        LGPL
PortSoundFile     MIT-style(?)
QuickTime         proprietary


I hope that this helps the discussion/decision!

Anthony Kozar
anthony.kozar@utoledo.edu

Thanks for that summary.  The previous message in my mail is from Erik
de Castro Lupo in response to my question about loop chunks.  I will
try to digest your useful comments.

==John ffitch

My PortSF is unrelated to any of the PortAudio initiatives such as 
PortSoundFile, which indeed does not exist. Erc's libsndfile has really 
already become the de facto premier library for soundfile support (a 
role I am more than happy to endorse), and it is difficult to imagine 
what a PortSoundFile library would have that was materially different. I 
also imagine that Eric would have much the same opinion.

My portsf library was developed initially as a means of exploring uses 
of WAVEFORMATEXTENSIBLE (e.g. for multi-channel and Ambisonic B Format 
data), and to develop and exploit the PEAK chunk. It only supports 
WAVE/WAVEX and AIFF/AIFF-C formats at present, i.e. no snd/au, no raw, 
no compressed formats. It is also aimed at pedagogical use (e.g. by 
being all confined to one or two source files, and aiming more for 
clarity than high optimization), and will therefore get published in due 
course. I will use it for the sources to the CDP Multi-Channel Toolkit 
when I get around to reorganising all the relevent programs and web 
pages.   There is much to do before it can be considered complete, 
though I have no interest in making it anything like as large or as 
comprehensive as libsndfile - no point! I want it to remain a "simple" 
compact library.

The library I made for the streaming pvoc opcodes for PVOCEX handling is 
  identical in design to portsf, so you can get a rough idea from that 
what portsf is like. It emulates the low-level open() and (write) C 
library functions, with integer file descriptors rather than opaque 
pointers. The read/write unit is the multi-channel sample frame; no 
support for raw char buffers.

The one advantage that portsf might offer to Csound is that it can be 
freely extended/modified to suit Csound's specific requirements, such as 
supporting loop points etc as first-class data, something that is 
certainly on my TODO list. It is as pure ANSI as I know how to make it, 
and does run on Windows/DOS32/OSX/Linux, and presumably other unix-like 
OSes. I did build and use it it successfully or MacOS 8x/9x, though I 
have carefully avoided spending much time on those! BeOS is not really 
in the picture any more, though building it on that would be no less 
trivial than building for Linux.

Before I publish the code more openly, I suspect I need to check with 
the PortAudio folk that my name "portsf" does not tread on any toes. I 
haven't thought of a viable alternative name yet! In the meastime, I am 
happy to send the sources to anyone interested.



Richard Dobson



Anthony Kozar wrote:
...
> PortSoundFile, a part of the PortMusic project directed by Ross Bencina and
> Phil Burk, would be nice from the perspective of being the companion to
> PortAudio and PortMidi.  However, it does not seem to actually exist yet
> (??).
> 
> John ff. mentioned Dobson's PortSF.  Is this the same as PortSoundFile which
> is part of PortMusic?  No other links to a "PortSF" showed up in a google
> search.
> 
...