- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am seeing inconsistent behavior between two versions of the FIRMR function that performs multi rate filtering. The version that works as expected is the ippsFIRMR_32fc function, the version that does not work as expected is ippsFIRMR_16sc.
Attached is the code used to show this difference. Note that the fc32 and 16sc versions are practically identical, the parts that differ are highlighted in the `Setup` struct.
The attached code can be compiled for the 16sc version by setting the parameter `use_16sc` to true. To compile the 32fc version set the `use_16sc` parameter to false. The 16sc version has a segfault while the 32fc version does not.
There are several things I have noticed that cause the segfault to occur:
- When the taps_len parameter is greater than or equal to 12 this segfault occurs. For 11 and under there is no segfault.
- If the second filter call is the exact same as the first then no segfault occurs. The segfault occurs when the role of the source and destination buffers are reversed.
The reason for reversing the buffers is to avoid copying or reallocating space for more buffers. After the first filter call the delay_src buffer serves no use so it should be reusable, such as the delay destination buffer for the second call to filter. After the first filter call the delay destination buffer should have values that are meant to be used as the delay source for the next filtering call. Note in the attached code we are simply using the same input and output buffers for both filter calls which is not realistic for an actual use case. It is done this way to simplify the example code displaying the bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your patience.
The fix will be available in a future release.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for posting the issue and providing out reproducer. We reproduced it with your sample code. And we will update here with further investigation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your patience.
The fix will be available in a future release.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for looking into this! I look forward to the next release
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel IPP 2022.1.0 is available for the fix.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page