GitLab

* 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

Some audio formats like `gsm` does not have valid frame numbers when opened. But `libsox` can properly handle these audios, so checking if `length > 0` is not necessary and too strict.

Numpy is a dependency of pytorch so we should let it get resolved as it
install pytorch
Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

* Fix fileobj I/O undeterministic behavior

Ever since the file-like object support was added in #1158, the test
was occasionally failing in CI. This PR fixes this.

Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/51319



We were going out of our way to accommodate `IValue::to<Tensor>` returning a copy of the inner Tensor. `IValue::toTensor` is capable of returning a reference without copying, so if we use it directly, we can allow kernels that want to take `Tensor &` to do so!
As a bonus, we get reduced build times.
ghstack-source-id: 121378961

Reviewed By: bhosmer

Differential Revision: D26138549

fbshipit-source-id: b0f830527da360c542c815bef2f7e1692615b32a
Co-authored-by: Scott Wolchok <swolchok@fb.com>

This reverts commit 93950302.

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

Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

After a9f5e7229 was merged into upstream pytorch the passing of
references within torch c extension functions is no longer allowed. This
just removes the reference and passes by value instead.
Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

Co-authored-by: Vincent QB <vincentqb@users.noreply.github.com>