Sqrt issue with M1 build

1

Hi, I already put up a bug report on GitHub but perhaps also good to share here; playing around with the m1 builds from the ‘actions’ tab but also with an earlier homegrown arm64 build based on the dev branch I found out that when you perform .sqrt on an audio rate Ugen output and the value is 0 (zero) it returns a NaN (and thus blocking all audio on the server). I tried the same thing with an intel build of the same dev version and there it behaves normal, so it’s arm64-only. Also in control rate it doesn’t happen. I’m wondering how this could be, and of course if it can be fixed. I imagine it can mess up quite some things, although not every user may stumble across it. But perhaps good to share here, also wondering if there could be more of these unexpected strange differences between the intel and arm builds…

Replicate:

{ DC.ar(0).sqrt }.plot; // NaN on arm64, 0 on intel

2

Maybe some internal NaN checking has changed? I had an issue where I started getting NaNs/infs in a feedback situation (LocalIn, LocalOut) where they hadn’t existed before. Clip and ReplaceBadValues solved the problem, but it took a hot minute to figure it out. I wouldn’t call my issue a bug, because I probably WAS creating the bad values before and they were getting squashed somewhere. It is more a change of functionality.

edit:[though of course sqrt of 0 should be 0]

Sam

3

Are you sure the NaN is really caused by sqrt and not by DC?

What happens if you do the following:
{ K2A.ar(0).sqrt }.plot;

4

both that and this:

{EnvGen.ar(Env([0,0,1], [0.01,0.01])).sqrt}.plot(0.02)

produce a NaN

5

Marcin looked into it last night. It appears to be related to the nova_simd library. We chatted about it last night and aren’t sure if the best solution yet.

/*
Josh Parmenter
www.realizedsound.net/josh
*/