Fix sf_open error checking when used concurrently

[jonashaag]

libsndfile error reporting is not thread safe, see libsndfile/libsndfile#279 libsndfile/libsndfile#610.

The patch does not attempt to fix that, but it changes the way errors are checked for in order to fix one specific race condition:

If opening a file not understood by libsndfile with sf.SoundFile, and then attempting to .read() from it, sometimes opening the file with sf.SoundFile does not report an error (due to the libsndfile race condition), and then the .read() fails. (As a consequence, librosa will not attempt to open the file using audioread, making librosa.load fail.)

[mgeier]

Thanks for the PR.

The behavior of libsndfile is unfortunate, but I think this PR is a good work-around.

It would probably be helpful for future readers of the code to include the above-mentioned libsndfile issue links as comments in the source code?

[jonashaag]

So, we made some progress in libsndfile#610 but I think we should merge this anyway as it is "more correct" this way.

[jonashaag]

Oh wow, Python 2.6 still supported... will have to adapt that test

[jonashaag]

Btw, why aren't Travis results shown here?

[mgeier]

Thanks for the updates!

[mgeier]

Btw, why aren't Travis results shown here?

Good question, I don't know, but I've also seen the effect on several of my projects.
For me, this was one more reason to switch from Travis-CI to Github Actions.

In case someone wants to see them, there are the Travis-CI logs: https://travis-ci.org/github/bastibe/SoundFile/pull_requests

[jonashaag]

Anything preventing this from being merged?