GitLab

Add torio top-level directory. It's not part of the package yet.

Differential Revision: D50197331

Pull Request resolved: https://github.com/pytorch/audio/pull/3654

Differential Revision: D50193749

Pull Request resolved: https://github.com/pytorch/audio/pull/3650

Differential Revision: D49965263

Pull Request resolved: https://github.com/pytorch/audio/pull/3639

Summary:
This commit updates the way libsox is integrated to torchaudio

1. We stop statically linking libsox, so torchaudio will not ship libsox.
2. We link libsox dynamically. Users are expected to install libsox by themselves.
3. We use stab library to build torchaudio.

Pull Request resolved: https://github.com/pytorch/audio/pull/3497

Differential Revision: D47803706

Pulled By: mthrok

fbshipit-source-id: 31b05495d81069186fa52d67beea360cc7e817a8

Summary:
This commit introduces support for multiple FFmpeg versions for OSS binary distributions.

Currently torchaudio only works with FFmpeg 4. This is inconvenient from installing to runtime linking.
This commit allows to pick FFmpeg 4, 5 or 6 at runtime, instead of just looking for v4.

The way it works is that we compile the FFmpeg extension three times with different FFmpeg and ship them.
At runtime, we look for libavutil of specific version and when one is found, load the corresponding FFmpeg extension.
The order of preference is 6, 5, then 4.

To make the build process simple and reproducible, we use pre-built binaries of FFmpeg during the build.
They are LGPL and downloaded from S3 at build time, instead of building every time.

The use of pre-built binaries as scaffolding limits the system that can build torchaudio, so it also introduces
single FFmpeg version support mode. setting FFMPEG_ROOT during the build will change the way binaries are built
so that it will only support one specific version of FFmpeg.

Pull Request resolved: https://github.com/pytorch/audio/pull/3464

Differential Revision: D47300223

Pulled By: mthrok

fbshipit-source-id: 560c7968315e4c8922afa11a4693f648c0356d04

Summary:
This commit removes file-like obejct support so that we can remove custom patch

The motivation and plan is outlined in https://github.com/pytorch/audio/issues/2950.

Pull Request resolved: https://github.com/pytorch/audio/pull/3035

Reviewed By: hwangjeff

Differential Revision: D44695647

Pulled By: mthrok

fbshipit-source-id: 13af0234e288c041bc7b490e1f967f85ce7eb8ec

Summary:
Utilities functions are only available to Python, so no need to use TorchBind for them.
This should allow us to remove link-whole flag when linking `libtorchaudio_ffmpeg` part.

Pull Request resolved: https://github.com/pytorch/audio/pull/3228

Reviewed By: nateanl

Differential Revision: D44639560

Pulled By: mthrok

fbshipit-source-id: 5116073ee8c5ab572c63ad123942c4826bfe1100

Summary:
Instead of raising an error when lazy import happens, this method allows to import features, and raises an error when the feature is being used.

This makes it easy to adopt the same error mechanism across different modules. It is how it's done for sox-related features.

Pull Request resolved: https://github.com/pytorch/audio/pull/3028

Reviewed By: xiaohui-zhang

Differential Revision: D42966976

Pulled By: mthrok

fbshipit-source-id: 423dfe0b8a3970cd07f20e841c794c7f2809f993

Summary:
* Refactor _extension module so that
  * the implementation of initialization logic and its execution are separated.
    * logic goes to `_extension.utils`
    * the execution is at `_extension.__init__`
    * global variables are defined and modified in `__init__`.
* Replace `is_sox_available()` with `_extension._SOX_INITIALIZED`
* Replace `is_kaldi_available()` with `_extension._IS_KALDI_AVAILABLE`
* Move `requies_sox()` and `requires_kaldi()` to break the circular dependency among `_extension` and `_internal.module_utils`.
* Merge the sox-related initialization logic in `_extension.utils` module.

Pull Request resolved: https://github.com/pytorch/audio/pull/2968

Reviewed By: hwangjeff

Differential Revision: D42387251

Pulled By: mthrok

fbshipit-source-id: 0c3245dfab53f9bc1b8a83ec2622eb88ec96673f

Summary:
Pull Request resolved: https://github.com/pytorch/audio/pull/2956

Merge utility binding

This commit updates the utility binding, so that we can use `is_module_available()`
for checking the existence of extension modules.

To ensure the existence of module, this commit migrates the binding of utility functions
to PyBind11.

Going forward, we should use TorchBind for ops that we want to support TorchScript,
otherwise default to PyBind11. (PyBind has advantage of not copying strings.)

Reviewed By: hwangjeff

Differential Revision: D42355992

fbshipit-source-id: 4c71d65b24a0882a38a80dc097d45ba72b4c4a6b

Summary:
Currently, importing TorchAudio triggers a check of the CUDA version it was compiled with, which in turn calls `torch.ops.torchaudio.cuda_version()`. This function is available only if `libtorchaudio` is available; developers, however, may want to import TorchAudio regardless of its availability. To allow for such usage, this PR adds code that bypasses the check if `libtorchaudio` is not available.

Pull Request resolved: https://github.com/pytorch/audio/pull/2952

Reviewed By: mthrok

Differential Revision: D42336396

Pulled By: hwangjeff

fbshipit-source-id: 465353cf46b218c0bcdf51ca5cf0b83c93185f39

Summary:
This commit makes the following changes to the C++ library organization
- Move sox-related feature implementations from `libtorchaudio` to `libtorchaudio_sox`.
- Remove C++ implementation of `is_sox_available` and `is_ffmpeg_available` as it is now sufficient to check the existence of `libtorchaudio_sox` and `libtorchaudio_ffmpeg` to check the availability. This makes `libtorchaudio_sox` and `libtorchaudio_ffmpeg` independent from `libtorchaudio`.
- Move PyBind11-based bindings (`_torchaudio_sox`, `_torchaudio_ffmpeg`) into `torchaudio.lib` so that the built library structure is less cluttered.

Background:
Originally, when the `libsox` was the only C++ extension and `libtorchaudio` was supposed to contain all the C++ code.
The things are different now. We have a bunch of C++ extensions and we need to make the code/build structure more modular.

The new `libtorchaudio_sox` contains the implementations and `_torchaudio_sox` contains the PyBin11-based bindings.

Pull Request resolved: https://github.com/pytorch/audio/pull/2929

Reviewed By: hwangjeff

Differential Revision: D42159594

Pulled By: mthrok

fbshipit-source-id: 1a0fbca9e4143137f6363fc001b2378ce6029aa7

Summary:
Return version from cuda version check so that we can display it in the test details

Pull Request resolved: https://github.com/pytorch/audio/pull/2919

Reviewed By: mthrok

Differential Revision: D42001252

Pulled By: atalman

fbshipit-source-id: 0d8fc3812a13fe098cdf8e0f3df7b66161ba3f95

Summary:
Fix windows python 3.8 loading path

Pull Request resolved: https://github.com/pytorch/audio/pull/2747

Reviewed By: nateanl

Differential Revision: D40264326

Pulled By: nateanl

fbshipit-source-id: f4a24757de7b48c63a7481034eb11fc3ff174327

Summary:
Torchaudio load libary path fix for windows and python = 3.8

Fixes: https://github.com/pytorch/audio/issues/2726

Fixes following issue:

```
>>> import torchaudio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\site-packages\torchaudio\__init__.py", line 1, in <module>
    from torchaudio import (  # noqa: F401
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\site-packages\torchaudio\_extension.py", line 128, in <module>
    _init_extension()
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\site-packages\torchaudio\_extension.py", line 98, in _init_extension
    _load_lib("libtorchaudio")
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\site-packages\torchaudio\_extension.py", line 52, in _load_lib
    torch.ops.load_library(path)
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\site-packages\torch\_ops.py", line 573, in load_library
    ctypes.CDLL(path)
  File "C:\Users\atalman\miniconda3\envs\mywin38\lib\ctypes\__init__.py", line 373, in __init__
    self._handle = _dlopen(self._name, mode)
FileNotFoundError: Could not find module 'C:\Users\atalman\miniconda3\envs\mywin38\Lib\site-packages\torchaudio\lib\libtorchaudio.pyd' (or one of its dependencies). Try using the full path with constructor syntax.
>>>
```

Caused by dlls not being found in the conda environment
```
C:\Users\atalman\miniconda3\envs\mywin38\bin\
```

While this environment is set correctly in PATH its ignored with Python = 3.8
Please refer to: https://stackoverflow.com/questions/59330863/cant-import-dll-module-in-python

Pull Request resolved: https://github.com/pytorch/audio/pull/2735

Reviewed By: carolineechen

Differential Revision: D40112293

Pulled By: carolineechen

fbshipit-source-id: c7fc9bb49fc3ec4a2855c6ea473f36808103ed1e

Summary:
`torch.version.cuda` can return a string of form X.X or X.X.X. This PR modifies the CUDA version check to account for this.

Pull Request resolved: https://github.com/pytorch/audio/pull/2710

Reviewed By: carolineechen, nateanl

Differential Revision: D39796810

Pulled By: hwangjeff

fbshipit-source-id: b483bd8200195844d65d0caddebaf1b10f939b64

Summary:
Adds check to ensure that TorchAudio and PyTorch versions use the same CUDA version.

Pull Request resolved: https://github.com/pytorch/audio/pull/2707

Reviewed By: mthrok

Differential Revision: D39791154

Pulled By: hwangjeff

fbshipit-source-id: de00889c7bac897c6b8762502f9d37797016b71d

Summary:
With the default log-level, completely sane operation like converting
YUV to RGB issues bunch of warnings like

`[swscaler @ 0x128aa8000] No accelerated colorspace conversion found from yuv420p to rgb24.`

This commit sets the log level to FATAL.

Pull Request resolved: https://github.com/pytorch/audio/pull/2447

Reviewed By: hwangjeff

Differential Revision: D36938728

Pulled By: mthrok

fbshipit-source-id: 39c2e6a4307f1eac577fd606e17ab0f298079b54

Summary:
Attempt to load ffmpeg extension at the top level import

Preparation to use ffmpeg-based I/O as a fallback for sox_io backend.

Pull Request resolved: https://github.com/pytorch/audio/pull/2417

Reviewed By: carolineechen

Differential Revision: D36736989

Pulled By: mthrok

fbshipit-source-id: 0beb6f459313b5ea91597393ccb12571444c54d9

Summary:
Part of https://github.com/pytorch/audio/issues/2164.
To make the tests introduced in https://github.com/pytorch/audio/issues/2164 skippable if ffmpeg features are not available,
this commit adds `is_ffmpeg_available`.

The availability of the features depend on two factors;
1. If it was enabled at build.
2. If the ffmpeg libraries are found at runtime.

A simple way (for OSS workflow) to detect these is simply checking if
`libtorchaudio_ffmpeg` presents and can be loaded without a failure.

To facilitate this, this commit changes the
`torchaudio._extension._load_lib` to return boolean result.

Pull Request resolved: https://github.com/pytorch/audio/pull/2170

Reviewed By: carolineechen

Differential Revision: D33797695

Pulled By: mthrok

fbshipit-source-id: 85e767fc06350b8f99de255bc965b8c92b8cfe97

Summary:
Pull Request resolved: https://github.com/pytorch/audio/pull/2096

run: `arc lint --apply-patches --paths-cmd 'hg files -I "./**/*.py"'`

Reviewed By: mthrok

Differential Revision: D33297351

fbshipit-source-id: 7bf5956edf0717c5ca90219f72414ff4eeaf5aa8

Summary:
(This is a part of refactor series, followed up by https://github.com/pytorch/audio/issues/2039 and https://github.com/pytorch/audio/issues/2040.
The goal is to make it easy to add a new library artifact alongside with `libtorchudio`, as in https://github.com/pytorch/audio/pull/2048/commits/4ced990849e60f6d19e87ae22819b04d1726648e https://github.com/pytorch/audio/issues/2048 .)

We plan to add prototype/beta third party library integrations,
which could be unstable. (segfault, missing dynamic library dependencies etc...)

If we add such integrations into the existing libtorchaudio,
in the worst case, it will prevent users from just `import torchaudio`.

Instead, we would like to separate the prototype/beta integrations
into separate libraries, so that such issues would not impact all users but
users who attempt to use these prototytpe/beta features.

Say, a prototype feature `foo` is added in `torchaudio.prototype.foo`.
The following initialization procedure will achieve the above mechanism.

1. Place the library file `libtorchaudio_foo` in `torchaudio/lib`.
2. In `torchaudio.prototype.foo.__init__.py`, load the `libtorchaudio_foo`.

Note:
The approach will be slightly different for fbcode, because of how buck deploys
C++ libraries and standardized environment, but the code change here is still
applicable.

Pull Request resolved: https://github.com/pytorch/audio/pull/2038

Reviewed By: carolineechen, nateanl

Differential Revision: D32682900

Pulled By: mthrok

fbshipit-source-id: 0f402a92a366fba8c2894a0fe01f47f8cdd51376

Make the structure of library files somewhat similar to PyTorch core, which has the following pattern

```
torch/_C.so
torch/lib/libc10.so
torch/lib/libtorch.so
...
```

```
torchaudio/_torchaudio.so
torchaudio/lib/libtorchaudio.so
```

* Split `libtorchaudio` and `_torchaudio`

This change extract the core implementation from `_torchaudio` to `libtorchaudio`,
so that `libtorchaudio` is reusable in TorchScript-based app.

`_torchaudio` is a wrapper around `libtorchaudio` and only provides PyBind11-based
features. (currently file-like object support in I/O)

* Removed `BUILD_LIBTORCHAUDIO` option

When invoking `cmake`, `libtorchaudio` is always built, so this option is removed.

The new assumptions around the library discoverability

- In regular OSS workflow (`pip`/`conda`-based binary installation), both `libtorchaudio` and `_torchaudio` are present.
    In this case,`libtorchaudio` has to be loaded manually with `torch.ops.load_library` and/or `torch.classes.load_library` otherwise importing `_torchaudio` would not be able to resolve the symbols defined in `libtorchaudio`.
- When `torchaudio` is deployed with PEX format (single zip file)
  - We expect that`libtorchaudio.so` exists as a file in some search path configured by client code.
  - `_torchaudio` is still importable and because we do not know where `libtorchaudio` will exist, we will let the dynamic loader resolve the dependency from `_torchaudio` to `libtorchaudio`, which should work as long as `libtorchaudio` is in a library search path (search path is not modifiable from already-running Python process).