You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since 7204125, behavior differs around extreme inputs. Comparing renderer output, some samples are off-by-one in a random direction.
Using the test midi here: nukeykt#101
Renderer output for upstream (left) and local (right)
Under normal circumstances, this doesn't happen - all the current integration tests produce bitwise identical results to upstream. When it does happen, inverting one of the two rendered waveforms produces near total silence, so there's not an audible difference between the two implementations. I have also been running a local validation branch that performs range checks on the output of these functions for the past 4 months, and it hasn't trapped yet except on this test midi. I trust the optimization to be sound since the midi also produces crackling with upstream.
It's not clear what the intended behavior is so I'll wait for someone with actual hardware or more insight into the problem before deciding whether or not this optimization needs to be reverted.
The text was updated successfully, but these errors were encountered:
The patch I posted in the linked issue fixes this problem and produces identical sample output; waiting for feedback from someone who knows the hardware better in case it's the incorrect approach.
Since 7204125, behavior differs around extreme inputs. Comparing renderer output, some samples are off-by-one in a random direction.
Using the test midi here: nukeykt#101
![image](https://private-user-images.githubusercontent.com/1007628/378228095-479fa20d-03f2-4286-a084-c9d10f3321b2.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxMDM0MTAsIm5iZiI6MTczOTEwMzExMCwicGF0aCI6Ii8xMDA3NjI4LzM3ODIyODA5NS00NzlmYTIwZC0wM2YyLTQyODYtYTA4NC1jOWQxMGYzMzIxYjIucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIwOSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMDlUMTIxMTUwWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9N2Q5ZjAxOGUwYjZhYjA1YmY4YTRkZjM4NTQyOTFiM2QzNmZiOWIwYTU0NWU2NDE5MTEyOTYwYmUxNzFiY2IzOSZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.q9azjirp2UF2KLEJejL2lUzzvM1VLiFhAlK2bGP7dpY)
Renderer output for upstream (left) and local (right)
Under normal circumstances, this doesn't happen - all the current integration tests produce bitwise identical results to upstream. When it does happen, inverting one of the two rendered waveforms produces near total silence, so there's not an audible difference between the two implementations. I have also been running a local validation branch that performs range checks on the output of these functions for the past 4 months, and it hasn't trapped yet except on this test midi. I trust the optimization to be sound since the midi also produces crackling with upstream.
It's not clear what the intended behavior is so I'll wait for someone with actual hardware or more insight into the problem before deciding whether or not this optimization needs to be reverted.
The text was updated successfully, but these errors were encountered: