Skip to content

fix: Use explicit Int64 tensor type for Silero VAD sample rate input#35

Draft
EgilSandfeld wants to merge 4 commits intosandrohanea:mainfrom
EgilSandfeld:main
Draft

fix: Use explicit Int64 tensor type for Silero VAD sample rate input#35
EgilSandfeld wants to merge 4 commits intosandrohanea:mainfrom
EgilSandfeld:main

Conversation

@EgilSandfeld
Copy link

The Silero VAD ONNX model expects tensor(int64) for the 'sr' input, but was receiving tensor(float) due to implicit type inference issues.

  • Use OrtValue.CreateTensorValueFromMemory() to explicitly create Int64 tensor
  • Add using directive for Microsoft.ML.OnnxRuntime.Tensors
  • Fixes ONNX Runtime input type mismatch error

Problem

The Silero VAD ONNX model expects tensor(int64) for the 'sr' (sample rate) input, but was receiving tensor(float) due to implicit type inference issues in ONNX Runtime. This caused the following error:

Unexpected input data type. Actual: (tensor(float)) , expected: (tensor(int64))

Solution

Use OrtValue.CreateTensorValueFromMemory<long>() to explicitly create an Int64 tensor for the sample rate input.

Changes

  • Use OrtValue.CreateTensorValueFromMemory<long>(sampleRateInput, [1]) to explicitly create Int64 tensor
  • Add using directive for Microsoft.ML.OnnxRuntime.Tensors

Testing

  • Build succeeds on all target frameworks (netstandard2.0, net8.0, net9.0)
  • All existing tests pass (99 passed on net9.0, 101 passed on net472)

The Silero VAD ONNX model expects tensor(int64) for the 'sr' input, but
was receiving tensor(float) due to implicit type inference issues.

- Use OrtValue.CreateTensorValueFromMemory<long>() to explicitly create Int64 tensor
- Add using directive for Microsoft.ML.OnnxRuntime.Tensors
- Fixes ONNX Runtime input type mismatch error

Fixes sandrohanea#1
@sandrohanea
Copy link
Owner

Hello @EgilSandfeld and thanks for the contribution!
The fix is indeed great.

However, the standardize target framework to netstandard2.0 is breaking existing optimizations that are using preprocessor directives:

e.g.

#if NET8_0_OR_GREATER
    [LibraryImport("sherpa-onnx-c-api", EntryPoint = "SherpaOnnxAcceptWaveformOffline")]
    private static partial void AcceptWaveform(IntPtr handle, int sampleRate, IntPtr samples, int n);
#else
    [DllImport("sherpa-onnx-c-api", EntryPoint = "SherpaOnnxAcceptWaveformOffline")]
    private static extern void AcceptWaveform(IntPtr handle, int sampleRate, IntPtr samples, int n);
#endif

Place:


`
During build, now all code will use the else (DllImport code).

This is just some small example without much perf improvements, but there are other optimizations that really make more sense:

…s projects and adjust package versions"

This reverts commit 0ae78b8.
- Added `Microsoft.Bcl.AsyncInterfaces` to `EchoSharp.Whisper.net.csproj` and `EchoSharp.csproj`.
- Removed duplicate `Microsoft.Bcl.AsyncInterfaces` entry for `netstandard2.0` target.
- Introduced `System.Threading.Channels` package versions in `Directory.Packages.props`.
<PackageVersion Include="Microsoft.ML.OnnxRuntime" Version="1.23.2" />
<PackageVersion Include="Microsoft.ML.OnnxRuntime.Extensions" Version="0.14.0" />
<PackageVersion Include="System.Threading.Channels" Version="9.0.0" />
<PackageVersion Include="System.Threading.Channels" Version="10.0.0" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why adding these 2 different versions for the same package?

</ItemGroup>

<ItemGroup>
<PackageReference Include="Microsoft.Bcl.AsyncInterfaces" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be a transitive dependency from Whisper.net already for the required frameworks.

</ItemGroup>

<ItemGroup>
<PackageReference Include="Microsoft.Bcl.AsyncInterfaces" />
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed on dotnet target frameworks (net8 / net9) as a dependency?
I think those already have support for the required IAsyncEnumerable and do not require additional dependency.

@EgilSandfeld EgilSandfeld marked this pull request as draft February 25, 2026 06:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants