GitLab

1. `F.phase_vocoder` accepts Tensor with complex dtype.
    * The implementation path has been updated from #758 so that they share the same code path by internally converting the input Tensor to complex dtype and performing all the operation on top of it.
    * Adopted `torch.polar` for simpler Tensor generation from magnitude and angle.
2. Updated tests
    * librosa compatibility test for complex dtype and pseudo complex dtype
        * Extracted the output shape check test and moved it to functional so that it will be tested on all the combination of `{CPU | CUDA} x {complex64 | complex128}`
    * TorchScript compatibility test for `F.phase_vocoder` and `T.TimeStretch`.
    * batch consistency test for `T.TimeStretch`.

Co-authored-by: krishnakalyan3 <skalyan@cloudera.com>

Co-authored-by: krishnakalyan3 <skalyan@cloudera.com>

This PR additionally adds batching to kaldi compliance resample interface.

* Refactor Kaldi compatibility tests
Co-authored-by: Jeff Hwang <jeffhwang@fb.com>

* Parameterize `test_sliding_window_cmn`

* Extract test naming function

* Pass a spectrogram to `F.sliding_window_cmn`

* Set manual seed for remaining rand calls in suite

[ghstack-poisoned]
Co-authored-by: Jeff Hwang <jeffhwang@fb.com>

Parameterize `test_create_fb` so each set of values are tested
independently. Also explicitly skip on older versions of librosa (< 0.7.2) when
`norm="slaney"`.

* Test with batches of differing items

Issues that occur when different items in a batch influence one another
will not present when a batch is composed of identical items. When
checking the consistency of batched behavior, in order to catch these
issues items should be different.

Thus, use different items for the `functional` batch consistency tests
wherever possible.

* Generate different white noise in each channel

Don't duplicate a single channel multiple times. Since this is used for
testing, generate different noise in each channel so data leakage
between channels can be detected.

* Parameterize batch size in batch consistency tests

Rather than creating a batch of 3 items in each test and slicing it to
test two different batch sizes at once, parameterize the batch size on
the TestFunctional class itself. This will generate a separate set of
tests for each batch size (better isolating failures) and removes a
leaky abstraction where the test calling `assert_batch_consistencies`
had to know to give it a batch size greater than 1.

* Check inputs too, to catch in-place operations

Check inputs to the batch consistency operations too, to ensure any
in-place operations operate the same on items as batches - not just that
they output the same result.

* Use much shorter sample for phaser test

Using a 5-second signal for the phaser test takes a long time on CPU,
much longer than the other batch consistency tests. Use a shorter signal
instead.

* Load dual-channel wav for VAD test

The stereo wav has two channels, slightly offset, so they'll count as
different items.

* Load wav using common_utils, not torchaudio.load

* Test pitch frequency with different freqs per item

The pitch frequency batch test was using the same frequency for each
item, which may not catch data leakage between items within a batch. Use
different frequencies so these kinds of issues would be triggered, just
like the other batch consistency tests.

* Explain justification for single-item batch

This reverts commit 93950302.

Remove duplicate --bits command line parameter. It's producing a warning with sox.