The apply_codec function does not behave normally

[changtaoli]

🐛 Describe the bug

I am trying to convert an audio tensor into 'gsm' format to simulate communication process with this apply_codec function. However, beside a transformed tensor, this function also returns a string: formats: gsm can't encode GSM to 16-bit.

The version I am using is 0.10.1 and this function will not return this string when using earlier version.

Versions

Collecting environment information... PyTorch version: 1.10.1 Is debug build: False CUDA used to build PyTorch: 11.3 ROCM used to build PyTorch: N/A OS: Ubuntu 20.04.3 LTS (x86_64) GCC version: (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Clang version: Could not collect CMake version: Could not collect Libc version: glibc-2.31 Python version: 3.9.7 (default, Sep 16 2021, 13:09:58) [GCC 7.5.0] (64-bit runtime) Python platform: Linux-5.11.0-43-generic-x86_64-with-glibc2.31 Is CUDA available: True CUDA runtime version: Could not collect GPU models and configuration: GPU 0: NVIDIA GeForce RTX 2080 Ti GPU 1: NVIDIA GeForce RTX 2080 Ti GPU 2: NVIDIA GeForce RTX 2080 Ti GPU 3: NVIDIA GeForce RTX 2080 Ti

Nvidia driver version: 470.86 cuDNN version: Could not collect HIP runtime version: N/A MIOpen runtime version: N/A Versions of relevant libraries: [pip3] numpy==1.20.3 [pip3] torch==1.10.1 [pip3] torchaudio==0.10.1 [pip3] torchvision==0.11.2 [conda] blas 1.0 mkl defaults [conda] cudatoolkit 11.3.1 h2bc3f7f_2 defaults [conda] ffmpeg 4.3 hf484d3e_0 pytorch [conda] mkl 2021.4.0 h06a4308_640 defaults [conda] mkl-service 2.4.0 py39h7f8727e_0 defaults [conda] mkl_fft 1.3.1 py39hd3c417c_0 defaults [conda] mkl_random 1.2.2 py39h51133e4_0 defaults [conda] numpy 1.20.3 pypi_0 pypi [conda] pytorch 1.10.1 py3.9_cuda11.3_cudnn8.2.0_0 pytorch [conda] pytorch-mutex 1.0 cuda pytorch [conda] torchaudio 0.10.1 py39_cu113 pytorch [conda] torchvision 0.11.2 py39_cu113 pytorch

[mthrok]

Hi @changtaoli

Thanks for the report. IIRC, nothing about that function is changed, but let us look into it.

I think you can suppress the warning with the utility. https://pytorch.org/audio/stable/utils.html#torchaudio.utils.sox_utils.set_verbosity

[marvin-nj]

Hi @changtaoli

Thanks for the report. IIRC, nothing about that function is changed, but let us look into it.

I think you can suppress the warning with the utility. https://pytorch.org/audio/stable/utils.html#torchaudio.utils.sox_utils.set_verbosity

really, it does't works when i set log level 1.

so, what should we do.

versions : torch 1.10.1+cu113 , torchaudio 0.10.1+cu113

[Epiphero]

I'm struggling with this too. I've tried set_verbosity(1), and I've even tried redirecting STDERR, but I can't get it to go away. Trying to use this for augmentation leaves me with millions of these messages in my logs. Any fix would be appreciated.

Having poked around in the source, it seems to be the saving to GSM format that's causing the problem, so a minimal piece of code to reproduce the problem is:

audio_tensor, sample_rate = torchaudio.load(filename)
assert sample_rate == 8000
bytes = io.BytesIO()
torchaudio.backend.sox_io_backend.save(
    bytes, audio_tensor, 8000, True, None, 'gsm', None, None
)

[DanTremonti]

Hi, is there any available workaround to suppress this message? I'm facing the same issue as @Epiphero -

Trying to use this for augmentation leaves me with millions of these messages in my logs. Any fix would be appreciated.

[SangwonSUH]

Have the same issue with the following env

pytorch                   2.0.1           py3.8_cuda11.8_cudnn8.7.0_0    pytorch
torchaudio                2.0.2                py38_cu118    pytorch

[mthrok]

Hi

It's long overdue for this issue, but

1. I cannot reproduce the issue on my end
2. We have made a significant change in how to integrate libsox. We no longer ship custom libsox, and apply_codec function does not use io.Bytes. Instead it writes to a temporary file. It is now recommended to use torchuadio.io.AudioEffector.

Due to these changes, I cannot tell easily if the issue still persists. Therefore, I close this issue and ask folks to open a new issue with the latest version. (nightly build or 2.1 version to be released in Oct 2023)

I regret to say that our resource is limited and it is unlikely we prioritize libsox-related issues.