moto

cc. @dongreenberg @cpuhrsch I think this is very reasonable, there is a similar work going for torchaudio too. We should resume the library naming convention discussion and wrap it up...

@oke-aditya The domain team had a brief discussion on this; * we agree that domain specific loss functions are coming up. * But we would like to hold off on...

> @mthrok is there also plans to adopt autosummary for the [torchaudio](https://pytorch.org/audio/main/torchaudio.html), [torchaudio.kaldi_io](https://pytorch.org/audio/main/kaldi_io.html), and [torchaudio.backend](https://pytorch.org/audio/main/backend.html) sections? @carolineechen Not at the moment. It is a bit complicated for `torchaudio.backend` but should...

Hi @maxwellzh This is due to the change made in v0.12. Loading MP3 is now delegated to FFmpeg in TorchAudio, but `apply_effects_file` cannot do that. As an alternative, can you...

Hi @BriansIDP I do not have a guess for how this happens. Perhaps can you share a build log?

What does the following command say? `nm /rds/project/rds-KQ4S3rlDzm8/gs534/audio/third_party/install/lib/libsox.a | grep gsm_create` (or `nm third_party/install/lib/libsox.a | grep gsm_create` from the source directory)

That suggests that libsox build process is not working as expected. Can you share the following logs? `build/temp.XXX/third_party/sox/src/sox-stamp/sox-configure.log` `build/temp.XXX/third_party/sox/src/sox-stamp/sox-build.log`

Thanks. The sox is configured to depend on external libgsm. I see the following line in your log, `gsm........................yes (external)` whereas mine says `gsm........................yes (in-tree)`. Perhaps possible explanation is that...

^ And when you try rebuilding, please remove the directory `third_party/install/lib` each time, just to be sure.

Looking at the new log, it seems that `--with-dyn-default=false` had the opposite of the desired effect, making all plug-ins external, while I hoped it will disable the dynamic dependence of...