libsndfile

libsndfile is a C library for reading and writing files containing sampled audio data.

Hacking

The canonical source code repository for libsndfile is at https://github.com/erikd/libsndfile/.

You can grab the source code using:

$ git clone git://github.com/erikd/libsndfile.git

For building for Android see BuildingForAndroid.

There are currently two build systems; the official GNU autotool based one and a more limited and experimental CMake based build system. Use of the CMake build system is documented below.

To build libsndfile on Linux, OSX and Windows (Using GNU GCC) from a git clone using the autotools based build system will require a number of GNU and other Free and Open Source Software tools including:

• Autoconf
• Autogen
• Automake
• Libtool
• Pkgconfig
• Python

If you are on Linux, its probably best to install these via your Linux distribution's package manager.

If you want to compile libsndfile with support for formats like FLAC and Ogg/Vorbis you will also need to install the following optional libraries:

• FLAC
• libogg
• libvorbis

Support for these extra libraries is an all or nothing affair. Unless all of them are installed none of them will be supported.

$ ./autogen.sh

Running autogen.sh also installs a git pre-commit hook. The pre-commit hook is run each time a user tries to commit and checks code about to be committed against coding guidelines.

Nest step is to run configure, with the following configure options being recommended for anyone contemplating sending libsndfile patches:

$ ./configure --enable-gcc-werror

Finally libsndfile can be built and tested:

$ make
$ make check

The CMake build system.

The CMake build system is still experimental and probably only works on linux because it still relies on GNU autotools for bootstrapping. Using it as simple as:

$ Scripts/cmake-build.sh

Will happily accept patches to make the CMake build system more portable.

Submitting Patches.

• Patches should pass all pre-commit hook tests.
• Patches should always be submitted via a either Github "pull request" or a via emailed patches created using "git format-patch".
• Patches for new features should include tests and documentation.
• Patches to fix bugs should either pass all tests, or modify the tests in some sane way.
• When a new feature is added for a particular file format and that feature makes sense for other formats, then it should also be implemented for one or two of the other formats.