Clarify exception for samplerate mismatch with WASAPI shared mode

[hiccup7]

When using WASAPI shared mode in Windows, it is necessary to match the samplerate in sounddevice
and Control Panel > Sound > device > Properties > Advanced tab > Default Format.
In sounddevice v0.3.5, a samplerate mismatch throws an exception "sounddevice.PortAudioError: Error opening RawOutputStream: Invalid device".
I propose to instead detect the mismatch to the device default samplerate and clarify the exception message. This will better help users understand and fix this type of problem. Often, they will want to change the Windows setting.

[mgeier]

The relevant part of the error message ("Invalid device") comes directly from the PortAudio library. You should probably move your request there: https://app.assembla.com/spaces/portaudio/tickets/.

[mgeier]

We could, however, try to improve the sounddevice documentation regarding this problem.
Feel free to submit a PR!

[hiccup7]

In the case of WASAPI shared mode, how about if sounddevice.query_devices(id_num) is automatically called before opening a stream with PortAudio? If the device default samplerate does not match the samplerate requested by the user, raise a Python exception with a meaningful message. This way, the PortAudio error does not happen.

[mgeier]

This would be too much of a hack for my taste. A proper solution can only be done in PortAudio itself.

@hiccup7 You should create an issue there!

[hiccup7]

I agree that PortAudio is the best and cleanest place to make this change. However, I don't have the experience of C coding to have an intelligent response if the PortAudio team objects. I also don't have the ability to compile the PortAudio source code to report back my testing results.

I submitted this issue here because I see sounddevice users are confused about WASAPI failures. This was the only practical solution I could think of to help these sounddevice users (and prevent unnecessary sounddevice issues posted).

My experience with my USB external DAC is that sounddevice works using the WDM-KS and WASAPI shared mode host APIs, while PyAudio from the following site does not:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyaudio
Thus, I find sounddevice is already more mature and easier to use than PyAudio on Windows. In fact, I propose changing the development status to beta here: https://pypi.python.org/pypi/sounddevice/
Clarifying the Python exception for samplerate mismatch with WASAPI shared mode is useful step toward sounddevice being ready for version 1.0.

[mgeier]

@hiccup7 No excuses! You should tell the PortAudio people, don't be shy! If you need help, feel free to ask me (note, however, that I have no clue about Windows).

BTW, I just tried using the wrong samplerate with JACK, and there the error message is -- as it should be:

Invalid sample rate

If you add an issue for PortAudio, I might add a special WASAPI error message to the sounddevice module.

... easier to use than PyAudio on Windows

This was one of the reasons why I created the sounddevice module in the first place. It's nice to hear that it works well.

I propose changing the development status to beta

I won't do that anytime soon. "beta" normally means feature completeness, and I'm not sure that's reached yet. Also it implies some kind of release schedule, which I don't have.
As long as I'm the only programmer and maintainer, I don't want to promise anything.

... step toward sounddevice being ready for version 1.0

To come anywhere near 1.0, we would at least need:

• automated tests
• multiple contributors
• more than one maintainer

If you think "alpha" is misleading in the current situation, I'm willing to completely remove the "development status" information. I'm not sure how useful this is anyway. I think the activity and stars on Github are much more informative than some arbitrarily chosen "development status".

[hiccup7]

See my positive review of sounddevice in this thread: winpython/winpython#428
The WinPython developer is concerned about adding sounddevice to WinPython because of the development status of "3 - Alpha". Since we got WASAPI exclusive mode to work, I declare that sounddevice rocks!

[mgeier]

@hiccup7 Thanks for your support!

I've removed the "development status" in d684d34. Anything else to do regarding winpython/winpython#428?

[hiccup7]

How about a new release of sounddevice on PyPI with the updated PortAudio version in the wheels? Then users who have a bad experience with WASAPI exclusive mode or other issues understand they need to update.

[mgeier]

Sure, will do. I'm just waiting for confirmation if the 32-bit DLL and the Mac dylib work (including on OSX 10.6).

[hiccup7]

Notice in winpython/winpython#428 that the developer has agreed to add sounddevice in the next build.

[hiccup7]

WinPython is Windows only. Now that you have confirmation of the Windows 32-bit DLL, it would be good to do a release before the next WinPython release.

[mgeier]

@hiccup7 When is the deadline for the WinPython release?

[hiccup7]

See winpython/winpython#422 for WinPython test builds.
I am under the impression from winpython/winpython#428 that sounddevice will be included in the next test build, unless you tell him to wait. You may also want to state your preference for whether he uses cgohlke's wheels for sounddevice 0.3.5, which already have the latest stable PortAudio DLLs, or your next release. Either way, I suggest you ask Windows users on the sounddevice project to test your preferred wheel. If you prefer he use your next release, be aware that early WinPython builds get more testing (and opportunity to fix) before the WinPython release. If you want to change something other than the DLLs, I suggest negotiating your release date with the WinPython developer.

[mgeier]

I will not contact them, but if you tell me a concrete deadline, I can try to make the next release until then. But I'm making no promises.

TBH, I don't care which DLLs they use, I'm sure they know better than me.
If the Gohlke DLLs are better than mine, I can also use his for future sounddevice releases. I was only creating my own DLLs because at the time I couldn't find any that included all possible host APIs.

[hiccup7]

Your DLLs are a great service to the Python community because it causes sounddevice to be cross-platform and serve more users. My great experience with sounddevice caused Gohlke to support it and WinPython to include it.

Your DLLs continue to offer the advantage of letting the user replace it manually in the _sounddevice_data folder.
Gohlke's DLLs offer the advantage of being compiled with the MS Visual Studio specific to each Python version.

I don't understand the details, but Gohlke's DLLs may avoid problems with mismatches between the MS C Runtime library used for the DLL compile vs. the one used by different Python versions. Maybe you avoided this problem already by using CFFI's ABI in-line mode.

[mgeier]

I'm glad that my DLLs are useful to somebody.
You could still put Gohlke's DLLs into the _sounddevice_data folder, you just have to rename them to fit the original names. Or you could rename it to portaudio.dll and put it somewhere where CFFI can find it.

I didn't realize that Gohlke has different DLLs for each Python version. As long as people don't complain about my DLLs, I'll keep them as they are, but should there be problems, I can switch to Gohlke's DLLs and release different wheels for each Python version. Or someone else takes over the Windows maintenance, which would be even better.

[mgeier]

@hiccup7 Is there anything left to do in this issue?