This is a fork of the VAD engine that is part of the WebRTC Native Code package (https://webrtc.org/native-code/), for use as a standalone library independent from the rest of the WebRTC code. There are currently no changes in functionality.
libfvad uses autoconf/automake. After cloning the git repository, the
configure script can be generated using ./bootstrap
, afterwards the library
can be build and installed with the usual ./configure
, make
and
make install
.
An optional example can be enabled enabled by ./configure --enable-examples
.
This requires libsndfile (http://www.mega-nerd.com/libsndfile/, e.g.
apt install libsndfile1-dev
).
Tests can be run with make check
.
The API is documented in the include/fvad.h
header file.
This library largely consists of parts of the WebRTC Native Code package, the repository of which can be found at https://chromium.googlesource.com/external/webrtc:
- Most of
webrtc/common_audio/vad/
has been moved tosrc/vad
. - Parts of
webrtc/common_audio/signal_processing
have been moved tosrc/signal_processing
. Parts of this signal processing library not needed by the VAD engine have been removed. Also, some platform-specific assembly code has been removed for now, for easier maintainability. - Relevant unit tests have been converted into automake tests and moved to
tests
.
It is intended that future changes and fixes in the WebRTC Native Code package will also be be merged into libfvad.
To help with this, the libfvad git
repository has an upstream-import
branch containing the required subset of the
WebRTC Native Code package's files, and an upstream-renamed
branch which also
contains these unmodified files, but moved/renamed to the libfvad directory
structure.
The tools/import.sh
script is intended to be run in the
upstream-import
branch and imports changes from a local clone of the WebRTC
Native Code package git repository; it reads tools/import-paths
which contains
the list of files to import, and reads and updates tools/import-commit
which
contains the most recent imported commit hash of the source repository.
After this import, the changes can be merged first into the upstream-renamed
branch and then into the master
branch. The intermediate step is necessary
because git merge would treat files that were both renamed and heavily changed
as new files.