GitLab

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).