Remove generic lfilter loop

[samanklesaria]

The code for lfilter already has explicit cpu and CUDA. Do we really need a third fallback option? I guess there's an mps device type too. But shouldn't everything else get handled by cpu and cuda? If we removed the fallback, we wouldn't have to worry about porting the transpose, squeeze, and index_put operations to the stable ABI.

If it's important to keep support for other devices, we could also port this generic code to python instead.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/audio/4023

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• ghstack-mergeability-check and Check labels failing with 'Resource not accessible by integration'

❌ 7 New Failures

As of commit a86774c with merge base 6fbc710 ():

NEW FAILURES - The following jobs have failed:

• .github/workflows/bandit.yml (gh)
• .github/workflows/integration-test.yml (gh)
• .github/workflows/lint.yml (gh)
• .github/workflows/pr-labels.yml (gh)
• .github/workflows/unittest-macos-cpu.yml (gh)
• .github/workflows/unittest-windows-cpu.yml (gh)
• .github/workflows/unittest-windows-gpu.yml (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[NicolasHug]

Do we really need a third fallback option? I guess there's an mps device type too. But shouldn't everything else get handled by cpu and cuda?

I am not sure, but I don't think MPS devices would trigger either of the CPU/CUDA registered ops. I think it'd be safe to merge the PR if we can confirm that the M1 tests are passing... But we would need to re-enable them first.

[samanklesaria]

This PR will be converted back from draft once tests for MPS devices are turned on.