Get rid of typedefs/SignalInfo and replace AudioMetaData

[mthrok]

This PR removes typedefs.[h|cpp], moves SignalInfo from torchaudio namespace to torchaudio::sox_io, removes dummy module from Python interface, then replace info return type with AudioMetaData.

torchaudio::sox_io::SignalInfo struct was expected be data exchange structure between Python and C++ for all info, load and save function of sox_io backend. However, as I simplify the function signature of save and load, they end up not needing such structure, and now info function is the only function that use torchaudio::sox_io::SignalInfo struct.

On Python API level, we can replace this struct with simple Python class while keeping Torchscript-ability. This removes the necessity to introduce dummy module because we no longer need to annotate info function with torchaudio::sox_io::SignalInfo.

[codecov]

Codecov Report

Merging #761 into master will increase coverage by 0.19%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #761      +/-   ##
==========================================
+ Coverage   89.16%   89.35%   +0.19%     
==========================================
  Files          32       32              
  Lines        2566     2556      -10     
==========================================
- Hits         2288     2284       -4     
+ Misses        278      272       -6     

Impacted Files	Coverage Δ
torchaudio/extension/extension.py	100.00% <ø> (+20.00%)	⬆️
torchaudio/backend/sox_io_backend.py	78.12% <100.00%> (+5.04%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ad7f43f...c9eed5b. Read the comment docs.

[vincentqb]

LGTM

[vincentqb]

The functions are still in there so the change is not BC breaking, right? Is there a reason why you are updating the tests then?

[mthrok]

The functions are still in there so the change is not BC breaking, right?

No. These get_* functions are removed so this is BC breaking.

[vincentqb]

If a user tries to use them, what will happen? I don't see any instructions to the user on what to do?

[vincentqb]

Let's make sure we have the warnings in place to let the users know what to do if they encounter errors for missing operations.

[mthrok]

Let's make sure we have the warnings in place to let the users know what to do if they encounter errors for missing operations.

That approach is good for stable released feature, but considering the product lifecycle of "sox_io" backed, which is still under heavy development, I do not think that really fits.

[vincentqb]

Let's make sure we have the warnings in place to let the users know what to do if they encounter errors for missing operations.

That approach is good for stable released feature, but considering the product lifecycle of "sox_io" backed, which is still under heavy development, I do not think that really fits.

What I meant above when I asked if something was BC-breaking was whether this was changing the existing "sox" (not "sox_io") interface. "sox_io" has not been part of a release yet, so we don't need to add warnings when we are changing the interface.

• If this is not changing "sox" (and only changing "sox_io"), then there is no need for warnings and we can proceed.
• If this is changing "sox", then this is BC-breaking of a feature that was already in a torchaudio release, and we do need a warning.

Can you clarify the response?

[mthrok]

What I meant above when I asked if something was BC-breaking was whether this was changing the existing "sox" (not "sox_io") interface. "sox_io" has not been part of a release yet, so we don't need to add warnings when we are changing the interface.

This changes the function signature of sox_io backend and has nothing to do with sox backend.

[vincentqb]

Thanks for clarifying :) LGTM

[mthrok]

thanks