1. 06 Jan, 2022 1 commit
  2. 05 Jan, 2022 1 commit
  3. 30 Dec, 2021 1 commit
  4. 29 Dec, 2021 4 commits
  5. 28 Dec, 2021 3 commits
  6. 23 Dec, 2021 1 commit
  7. 21 Dec, 2021 1 commit
  8. 10 Dec, 2021 1 commit
  9. 03 Dec, 2021 1 commit
  10. 11 Nov, 2021 1 commit
  11. 10 Nov, 2021 1 commit
  12. 09 Nov, 2021 1 commit
  13. 05 Nov, 2021 5 commits
  14. 04 Nov, 2021 2 commits
  15. 03 Nov, 2021 1 commit
  16. 01 Nov, 2021 1 commit
  17. 30 Oct, 2021 1 commit
  18. 13 Oct, 2021 1 commit
  19. 11 Oct, 2021 1 commit
  20. 10 Oct, 2021 1 commit
    • moto's avatar
      Store n_bits in WaveRNN (#1847) · 9637c6bf
      moto authored
      Move the computation of `#classes -> #bits` to the constructor of WaveRNN and attach it to the instance, so that it can be reused elsewhere.
      9637c6bf
  21. 09 Oct, 2021 1 commit
  22. 07 Oct, 2021 1 commit
  23. 05 Oct, 2021 2 commits
  24. 30 Sep, 2021 1 commit
  25. 24 Sep, 2021 1 commit
  26. 22 Sep, 2021 1 commit
  27. 20 Sep, 2021 1 commit
  28. 17 Sep, 2021 1 commit
  29. 16 Sep, 2021 1 commit
    • moto's avatar
      Split extension into custom impl and Python wrapper libraries (#1752) · 0f822179
      moto authored
      * 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).
      0f822179