Fixes ASR numpy > 2.x compatibility issues while replicating existing behavior
State: open | Pull request: yes
Labels: name: ASR

# What does this PR do ?

The PR attempts to restore functionality with recent `numpy` versions; `numpy` 2.0 removed `sctypes` and this is breaking `asr` functionality.

**Collection**: `asr`

# Changelog 
- As said above `numpy` from version 2.0 onwards removed `sctypes` functionality, which breaks `asr` functionality in various places (e.g. transcribe_speech, example notebooks etc).
- The changes reside in the `_convert_samples_to_float32` function residing in both [feature_loader.py](https://github.com/NVIDIA/NeMo/blob/main/nemo/collections/asr/parts/preprocessing/feature_loader.py#48) and [segment.py](https://github.com/NVIDIA/NeMo/blob/main/nemo/collections/asr/parts/preprocessing/segment.py#257).
- There have been other issues relating to this (e.g. #10839 and #10180), however these _do not replicate existing functionality_.

# Usage

The usage is that ASR tasks that call `_convert_samples_to_float32` functions now succeed. As noted above, while this has been attempted to be addressed in the PRs mentioned above, I believe that the functionality is not replicated accurately.

More concretely, if you check the output of `sctype` for the types of `int` and `float` in supported versions of `numpy` you'd get the following:

```python
print(np.sctypes["int"])
[<class 'numpy.int8'>, <class 'numpy.int16'>, <class 'numpy.int32'>, <class 'numpy.int64'>]
print(np.sctypes["float"])
[<class 'numpy.float16'>, <class 'numpy.float32'>, <class 'numpy.float64'>]
```

However, if we use the `issubdtype` to perform this the set will be wider, case on point for floating point:

```python
import numpy as np
float128 = np.floating[128]
np.issubdtype(float128, np.floating)
Out[6]: True
```

And, also for integers the set mostly covers the output of `sctype` for _signed_ ones. However any subclass from `signedinteger` or `unsignedinteger` will return true. A more concrete example would be,

```python
import numpy as np
int96 = np.signedinteger[96]
np.issubdtype(int96, np.integer)
Out[4]: True
uint96 = np.unsignedinteger[96]
np.issubdtype(uint96, np.integer)
Out[5]: True
```

Therefore, in this case not only we consider `int{8,16,32,64}` but also `uint{8,16,32,64}` which is not the expected result when querying `sctype['int']` leading to potentially unexpected behavior. Case on point,

```python
import numpy as np
np.issubdtype(np.uint8, np.integer)
Out[3]: True
```

# GitHub Actions CI

The Jenkins CI system has been replaced by GitHub Actions self-hosted runners.

The GitHub Actions CI will run automatically when the "Run CICD" label is added to the PR.
To re-run CI remove and add the label again.
To run CI on an untrusted fork, a NeMo user with write access must first click "Approve and run".

# Before your PR is "Ready for review"
**Pre checks**:
- [x] Make sure you read and followed [Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md)
- [x] Did you write any new necessary tests? _No new tests were required._
- [x] Did you add or update any necessary documentation? _No documentation update required_.
- [ ] Does the PR affect components that are optional to install? (Ex: Numba, Pynini, Apex etc) _No optional components are affected_.
- [x] Reviewer: Does the PR have correct import guards for all optional libraries?
  
**PR Type**:
- [ ] New Feature
- [x] Bugfix
- [ ] Documentation

If you haven't finished some of the above items you can still open "Draft" PR.


## Who can review?

Anyone in the community is free to review the PR once the checks have passed. 
[Contributor guidelines](https://github.com/NVIDIA/NeMo/blob/main/CONTRIBUTING.md) contains specific people who can review PRs to various areas.

# Additional Information

The fix is _backwards compatible_ with all supported `numpy` 1.x versions as well. Therefore, it should pose minimal risk wrt to integration.


Note: I cannot seem to be able to request review for this PR, therefore based on contributing guidelines I am asking @titu1994 for one as that username was the first one in the list ;).  

<!-- pylint-output-strict-mode-false -->

beep boop 🤖: 🙏 The following files have warnings. In case you are familiar with these, please try helping us to improve the code base.

---

Your code was analyzed with PyLint. The following annotations have been identified:

```

------------------------------------
Your code has been rated at 10.00/10
```

---

Thank you for improving NeMo's documentation!

Maybe @redoctopus, @jbalam-nv, or @okuchaiev could review?

Would be great to get this merged as `numpy` 2.x is being iffy and always have to apply that patch ;)

This PR is stale because it has been open for 14 days with no activity. Remove stale label or comment or update or this will be closed in 7 days.

@oyilmaz-nvidia could you review this PR? It would be really nice if we could get support for numpy>2

Yeah, it'd be great if that's the case :). As I said, I have to apply this patch in order to get everything working properly when using `numpy` version >= 2.x.

Any updates on this one? :)