GitLab

It's wrong to depend on `${TORCH_LIBRARIES}` as it pulls in explicit
`libcuda.so.1` dependency, which violates the assumption that GPU
accelerated libraries should be loadable with no NVIDIA drivers installed

Instead, make it depend on `torch` target, which includes all necessary
Torch C++ API dependences

Calling `torch.[ops|classes].load_library(<PATH_TO_LIBRARY_FILE>)` is problematic in case `torchaudio`
is deployed with PEX format, because the library file does not exist as a file.

Our extension module, when it exists, is guaranteed to have PyBind11 binding even when no function is bound.
This allows to load the library using the regular `import` statement in Python, and it works even in PEX format.
When the library is loaded, the static initialization kicks in and the custom kernels bound via TorchScript also
become available. This removes the need to call `torch.[ops|classe].load_library`.

This works even when the implementation of custom kernel is stripped from `_torchaudio.so` so long as `_torchaudio.so` properly depend on the library that has the kernel implementations and static initialization.

Needed to support CUDA builds on CPU machine

Parse `TORCH_CUDA_ARCH_LIST` as new-CUDA-language Cmake-3.18+ style [CMAKE_CUDA_ARCHITECTURES](https://cmake.org/cmake/help/latest/prop_tgt/CUDA_ARCHITECTURES.html#prop_tgt:CUDA_ARCHITECTURES)

Copy `cuda_install.bat` from
https://github.com/pytorch/vision/blob/3d9d264198e2167030dc04bf453aeca47daa37db/packaging/windows/internal/cuda_install.bat

Add `windows_intall_cuda` step and include it in `binary_windows_conda`
and `binary_windows_wheel` workflows

That marks `.circleci/.config.yml` as auto-generated that excluding it
from code-reviews

Introduce a helper function `torch_script` that performs scripting in the recommended way.

* Default to BUILD_SOX=1 in non-Windows systems

Since the adaptation of CMake and restricting to the static linking of libsox,
the build process has become much robust with libsox integration enabled.

This commit makes it default behavior to build libsox integration in non-Windows systems.
The build process still checks BUILD_SOX env var so, setting `BUILD_SOX=0` disables it.

- Support three solutions for MVDR beamforming ("ref_channel", "stv_evd", "stv_power").
- Support single-channel and multi-channel time-frequency masks
- Add unit tests

* Add basic filtfilt implementation

* Add filtfilt to functional package; add tests
Co-authored-by: V G <vladislav.goncharenko@phystech.edu>

`torchaudio` treats `soundfile` as an optional dependency, and it assumes either `soundfile` is properly installed or it is not installed at all. However, there is a third state where `soundfile` is installed but the backing library `libsndfile` is not installed, and in this case, `import torchaudio` fails.

This commit resolves it by further checking if `soundfile` is importable. 

See also: https://github.com/pytorch/audio/issues/1687

When building torchaudio from source, `get_version.sh` from kaldi is executed everytime,
which results in kaldi-bindings to be always rebuilt.

This commit add "if" guard to the part so that they are not always executed.

* Reduce length of waveform in pitch_shift batch_consistency test

Summary: To address the test failure in T96406395

Reviewed By: carolineechen

Differential Revision: D30163741

fbshipit-source-id: f88d86b3da7b1ee52518934567b0b0a62700ee58

* Fix batch consistency test in transforms

Summary: The stress test still fails. Add n_fft to address it.

Reviewed By: mthrok

Differential Revision: D30218279

fbshipit-source-id: 7858efd3e5ac0073193a7883fd314486efc73814
Co-authored-by: Zhaoheng Ni <zni@fb.com>

BUILD_VERSION gets set by upstream scripts and should be available
whenever we're attempting to build audio in conda environments.

This solves the issue where conda packages appeared to be building a
development version instead of the actual version we were targeting
Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

- Provide InverseSpectrogram module that corresponds to Spectrogram module
- Add length parameter to the forward method in transforms
Co-authored-by: dgenzel <dgenzel@fb.com>
Co-authored-by: Zhaoheng Ni <zni@fb.com>

ref: D29989551

D30080845