Use soundfile for primary IO, fall back on audioread in emergencies

Description

As noted too many times in the issues to keep track of, the current audioread-based loader is both inefficient and somewhat finnicky across platforms and with varying back-end codec configurations. My recommendation has long been to use soundfile unless mp3 support is absolutely necessary, and plan to eventually switch over to soundfile in librosa once mp3 support is merged.

That said, there’s no reason we couldn’t have a soft dependency on soundfile as a first-pass attempt to load the data, and only fall back to audioread if soundfile fails for some reason (not installed, missing codec, etc). This would basically have librosa doing audioread’s job (multiplexing over decoding backends), but this is only a temporary situation until mp3 support arrives. In the meantime, we’d get faster loading and a more stable backend.

What do folks think?

[faroit]

We already have some docs on how to do this with sf: https://librosa.github.io/librosa/ioformats.html

yes, sure, I knew about this. What I meant is exactly how you implemented it in #847: rely on soundfile when it comes to seeking, thus avoid the outer loop. 👍

[faroit]

Another thing: since soundfile is in as a dependency, we could replace scipy.io.wavfile in the write_wav function (or make it a soft dependency as well). I could do a PR once the load/read is finished.