Fix analyzer sampling frequency check

[DradeAW]

Because of floating errors, the smapling frequency can be slightly different between recording and sorting

e.g. 30000.305042016807 and 30000.31

This fixes that issue (same code that was used in the waveform extractor)

[samuelgarcia]

thanks for this. We have a deeper problem for this. The sorter can round the sampleing rate and so in analyzer we should take the recording which is the one that have the most accurate normally unless we loose precision in the preprocessing.

[samuelgarcia]

I think that we should make a strict check and if this differ we warn the user and we force the sorting to have the exact same frequency than the recording. What do you think ? The most important is to warn the user.

[DradeAW]

I don't like warnings as a general rule, because in the case where it's not your fault and you're fine with it, it's annoying to see them pop up all the time ^^' But I'm fine with it if you think it's best

I'm completely fine with changing the sorting sampling frequency, since it's a copy (shared mem) and doesn't affect the original sorting object.

[h-mayorquin]

I think I agree with Sam here that the warning is the best option. I also think that warnings should be actionable by the user that receives them (i.e. there should be something they can do about it). For the case that @DradeAW describes, the action for the user (if they want to suppress the warning) is just to modify the sampling frequency of the sorter themselves, right? So that sounds an easy thing that they can do to remove the warning.

Unless the probablity of difference sampling frequencies causing and error is really really low, Sam proposal for being safe, seems like the way to go to me.

[alejoe91]

After discussing with @samuelgarcia we agree that we can be more "relaxed" about this, but we need to add a warning and use the recording sampling frequency as it is more reliable and change in-place the sorting one (since the analyzer creates its own copy of the sorting object)