Comments (18)
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/.
from python-sounddevice.
We could, however, try to improve the sounddevice
documentation regarding this problem.
Feel free to submit a PR!
from python-sounddevice.
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.
from python-sounddevice.
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!
from python-sounddevice.
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.
from python-sounddevice.
@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".
from python-sounddevice.
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!
from python-sounddevice.
@hiccup7 Thanks for your support!
I've removed the "development status" in d684d34. Anything else to do regarding winpython/winpython#428?
from python-sounddevice.
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.
from python-sounddevice.
Sure, will do. I'm just waiting for confirmation if the 32-bit DLL and the Mac dylib work (including on OSX 10.6).
from python-sounddevice.
Notice in winpython/winpython#428 that the developer has agreed to add sounddevice in the next build.
from python-sounddevice.
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.
from python-sounddevice.
@hiccup7 When is the deadline for the WinPython release?
from python-sounddevice.
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.
from python-sounddevice.
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.
from python-sounddevice.
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.
from python-sounddevice.
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.
from python-sounddevice.
@hiccup7 Is there anything left to do in this issue?
from python-sounddevice.
Related Issues (20)
- Raspberry pi: sounddevice query_devices() does not see usb devices HOT 2
- check_input_settings does not raise exception for some unsupported sample rates on macOS HOT 4
- Cannot get aggregate device to work with sounddevice/rtmixer signal processing.py example HOT 1
- Enhancement Request: Integrate Playback Status Check into Simple `play`/`stop` API in `sounddevice` HOT 4
- Feature request for loopback of output device. HOT 3
- 设备解码错误?utf-8' codec can't decode byte 0xc2 in position 6: invalid continuation byte HOT 4
- Sounddevice + big dict + OOP = Segfault / Bus Error HOT 11
- Update device list by reloading portaudio dll HOT 1
- Won't be able to import sounddevice due to unknown issue with `libportaudio64bit.dll` HOT 5
- Error opening OutputStream: Unanticipated host error', -9999, (2, 0, 'Failed to load ASIO driver
- Use sounddevice with virtual audio device and minimize latency HOT 1
- Achieving stable latency between calls of "playrec" HOT 8
- sounddevice not recognize all devices?
- Issues with playing concurrently with Youtube HOT 1
- Latency 30mSec HOT 9
- Advice on asynchronous playback HOT 7
- docker node minimal image
- Can I continue recording until the volume drops below a threshold? HOT 4
- Simultaneous audio playback datatype issue HOT 2
- Does sd.wait() block all other threads? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from python-sounddevice.