We want to make contributing to this project as easy and transparent as possible.
Please let us know if you encounter a bug by filing an issue.
We appreciate all contributions. If you are planning to contribute back bug-fixes, please do so without any further discussion.
If you plan to contribute new features, utility functions or extensions to the core, please first open an issue and discuss the feature with us. Sending a PR without discussion might end up resulting in a rejected PR, because we might be taking the core in a different direction than you might be aware of.
Facebook has a bounty program for the safe disclosure of security bugs. In those cases, please go through the process outlined on that page and do not file a public issue.
Fixing bugs and implementing new features are not the only way you can contribute. It also helps the project when you report problems you're facing, and when you give a 👍 on issues that others reported and that are relevant to you.
You can also help by improving the documentation. This is no less important than improving the library itself! If you find a typo in the documentation, do not hesitate to submit a pull request.
If you're not sure what you want to work on, you can pick an issue from the list of open issues labelled as "help wanted". Comment on the issue that you want to work on it and send a PR with your fix (see below).
In order to accept your pull request, we need you to submit a CLA. You only need to do this once to work on any of Facebook's open source projects.
Complete your CLA here: https://code.facebook.com/cla
We recommend using a conda
environment to contribute efficiently to
torchaudio.
conda install pytorch -c pytorch-nightly
# Install build-time dependencies
pip install cmake ninja pkgconfig
# Build torchaudio
git clone https://github.com/pytorch/audio.git
cd audio
git submodule update --init --recursive
python setup.py develop
# or, for OSX
# MACOSX_DEPLOYMENT_TARGET=10.9 CC=clang CXX=clang++ python setup.py develop
Some environmnet variables that change the build behavior
BUILD_SOX
: Deteremines whether build and bind libsox in non-Windows environments. (no effect in Windows as libsox integration is not available) Default value is 1 (build and bind). Use 0 for disabling it.USE_CUDA
: Determines whether build the custom CUDA kernel. Default to the availability of CUDA-compatible GPUs.
If you built sox, set the PATH
variable so that the tests properly use the newly built sox
binary:
export PATH="<path_to_torchaudio>/third_party/install/bin:${PATH}"
The following dependencies are also needed for testing:
pip install typing pytest scipy numpy parameterized
Optional packages to install if you want to run related tests:
librosa
requests
soundfile
kaldi_io
transformers
fairseq
(it has to be newer than0.10.2
, so you will need to install from source. Commite6eddd80
is known to work.)unidecode
(dependency for testing text preprocessing functions for examples/pipeline_tacotron2)inflect
(dependency for testing text preprocessing functions for examples/pipeline_tacotron2)
If you plan to modify the code or documentation, please follow the steps below:
- Fork the repository and create your branch from
main
:$ git checkout main && git checkout -b my_cool_feature
- If you have modified the code (new feature or bug-fix), please add tests.
- If you have changed APIs, update the documentation.
For more details about pull requests, please read GitHub's guides.
If you would like to contribute a new model, please see here.
If you would like to contribute a new dataset, please see here.
Please refer to our testing guidelines for more details.
Torchaudio uses Google style for formatting docstrings. Length of line inside docstrings block must be limited to 120 characters.
To build the docs, first install the requirements:
cd docs
pip install -r requirements.txt
Then:
cd docs
make html
The built docs should now be available in docs/build/html
As a good software development practice, we try to stick to existing variable names and shape (for tensors). The following are some of the conventions that we follow.
- We use an ellipsis "..." as a placeholder for the rest of the dimensions of a tensor, e.g. optional batching and channel dimensions. If batching, the "batch" dimension should come in the first diemension.
- Tensors are assumed to have "channel" dimension coming before the "time" dimension. The bins in frequency domain (freq and mel) are assumed to come before the "time" dimension but after the "channel" dimension. These ordering makes the tensors consistent with PyTorch's dimensions.
- For size names, the prefix
n_
is used (e.g. "a tensor of size (n_freq
,n_mels
)") whereas dimension names do not have this prefix (e.g. "a tensor of dimension (channel, time)")
Here are some of the examples of commonly used variables with thier names, meanings, and shapes (or units):
waveform
: a tensor of audio samples with dimensions (..., channel, time)sample_rate
: the rate of audio dimensions (samples per second)specgram
: a tensor of spectrogram with dimensions (..., channel, freq, time)mel_specgram
: a mel spectrogram with dimensions (..., channel, mel, time)hop_length
: the number of samples between the starts of consecutive framesn_fft
: the number of Fourier binsn_mels
,n_mfcc
: the number of mel and MFCC binsn_freq
: the number of bins in a linear spectrogramf_min
: the lowest frequency of the lowest band in a spectrogramf_max
: the highest frequency of the highest band in a spectrogramwin_length
: the length of the STFT windowwindow_fn
: for functions that creates windows e.g.torch.hann_window
By contributing to Torchaudio, you agree that your contributions will be licensed under the LICENSE file in the root directory of this source tree.