This seems fairly safe to me. Even if porting an old XNA game depended on it being range limited like it was before they surely didn't let it overflow and capture exceptions during gameplay.

The only thing i would suggest is to decide on what the rules are with range of the pitch moving forward. Do we guarantee at least 2 octaves on all platforms? Do we need more than 2 octaves?

While removing the limit here makes sense, we have to be careful as to which value we pass to the implementation. As of now, implementions are assuming this limit. Uncapping it might expose them to crashes.

For example, not all OpenAL implentations are equal, Android might crash below -1 and above 1, while on PC any value should be safe (OpenAL and XAudio should be able to support near infinite shifts on PC).

This PR looks safe in regard to DesktopGL and WindowsDX but we should safe check on mobile and consoles (I'll try to safe check the console side of things).

I looked into every platforms expected range and error handling:

• DesktopGL from float.MinValue to float.MaxValue (though we can expect the tolerance to be hardware dependent)
• WindowsDX from -10.0f to 10.0f (input values are clamped)
• Android from -1.0f to 1.0f (no clamping, error to be expected)
• iOS seems undocumented, it seems fair to assume that it's like Android (no clamping, error to be expected)
• Console 1 range from -4.0f to 4.0f (unspecified)
• Console 2 range from float.MinValue to 2.0f (no clamping, error to be expected)
• Console 3 range from float.MinValue to 2.0f (no clamping, error to be expected)
• Console 4 range from -10.0f to 10.0f (input values are clamped)

So in regard to this PR, we should add a clamp on OpenAL PlatformSetPitch(): -1;1 for mobiles, and something reasonable for DesktopGL (just to be safe, because I don't believe that anything beyond 10 is safe throughout all hardware, and I would even expect some hardware to fail way before that).

We have nothing to do for WindowsDX since it will clamp the values to +/- 10 octaves.

For consoles, we definitely need to add a clamp (I'll look into it if this PR moves forward).

@notexplosive if you address what @mrhelmut mentioned we can move forward with this. Or i can close it.

If I understand the feedback correctly, I think I did what @mrhelmut requested. (sorry for the force-push, I screwed up line endings and had to un-screw up the line endings).

Thank you for your patience! Sorry for leaving this PR for so long

Thank you for updating, and no worries, we're trying to catch up with PRs.

It seems that System.Math.Clamp(Single, Single, Single) doesn't exist on .NET 4.5 and it makes the console check to fail. This is however fine, we're soon going to switch over a more modern runtime. So I'm going to leave this PR unmerged for the time being and we'll merge it once that switch is made.

Thanks!