Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Audio device movement for cpu only augmentation #84

Open
DanTremonti opened this issue Jun 20, 2023 · 2 comments
Open

Audio device movement for cpu only augmentation #84

DanTremonti opened this issue Jun 20, 2023 · 2 comments

Comments

@DanTremonti
Copy link

DanTremonti commented Jun 20, 2023

Given that torchaudio.functional.apply_codec currently only supports "cpu" device ref, apply_codec effect may need moving the waveform to "cpu"

The below line of time_stretch effect

        waveform = self._to_2d().cpu()

moves the signal to "cpu", but the following line is from apply_codec effect

        waveform = self._to_2d()

If I'm not missing anything here, apply_codec effect is missing device handling.

Another small suggestion would be to have a flag that specifies if an effect does device movement. This will help users who are concerned about latency to effortlessly decide which effects to use, without having to look into every effect's implementation.

@pseeth
Copy link
Contributor

pseeth commented Jun 22, 2023

Oh, that's fair. I can look into that and roll it into the next release!

Re: device movement, I think it should be possible to add something that moves back to the original device after the effect. The only reason for an effect to have device movement is because the underlying code doesn't support the original device. So I think we should just move stuff back to the original device, and allow users to just select latency by doing .cuda or .cpu calls between effects on the signal.

@DanTremonti
Copy link
Author

DanTremonti commented Jun 23, 2023

So I think we should just move stuff back to the original device

Yes, you are right. I was implying the same as well. But, like you also mentioned,

only reason for an effect to have device movement is because the underlying code doesn't support the original device

I was merely suggesting to let user know, at least through docstring, that an effect is applied on cpu (despite moving back to input device).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants