New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RtAudio.cpp needs to include more headers for DirectSound #78
Comments
any idea if adding those lines could break things on older systems? |
By the way could you have a look at #75 and say whether you have had any related issues with Windows 10? |
With regard to breaking older systems, that seems most unlikely. A search of the copyright date of each header reveals that mmsystem.h has a copyright range between 1992-1998, where mmreg has a copyright between 1991-1998. So, it's probably safe to say that any reasonable system you'd want to support has those headers. Even if it does manage to break some very old system, installing the DirectX SDK would surely solve the problem. With respect to #75 I have not experiences those issues. That's probably because that person was using mingw, and I am not. However, I also observed one of the commenters said he was trying to compile WASAPI, whereas my suggestion pertains only to DirectSound support. It is possible that my suggestion, if implemented in the WASAPI section, may have fixed his issue. But since I don't use that interface, I can't confirm it. |
Thanks! Yes, I think it's safe to add includes for mmsystem and mmreg, just weird that it wasn't necessary before and now apparently it is. I'll make a pull request for further discussion. Some more people who actually have Windows 10 should test, perhaps. (I think most rtaudio developers do not have Windows, now that would be a useful case for using something like Travis... too bad it doesn't support Windows.) |
It was strange, too. For one of my projects, the existing headers in RtAudio worked great. But once I moved to an MFC project, it didn’t. It was probably a header order issue, but RtAudio should just explicitly include everything it needs. From: Stephen Sinclair [mailto:notifications@github.com] Thanks! Yes, I think it's safe to add includes for mmsystem and mmreg, just weird that it wasn't necessary before and now apparently it is. I'll make a pull request for further discussion. Some more people who actually have Windows 10 should test, perhaps. (I think most rtaudio developers do not have Windows, now that would be a useful case for using something like Travis... too bad it doesn't support Windows.) — |
Ah, but in that case I'd be interested to know more details of what the actual error is, because I'm looking through the DirectSound part of RtAudio.cpp and I don't see what could need anything in mmsystem or mmreg. |
Maybe MUTEX stuff? |
If these headers are not included dsound.h will not see certain definitions it needs. First and foremost, WAVEFORMATEX will not be defined. So really MS should have included those in dsound.h, probably, but you know that will never change. From: Stephen Sinclair [mailto:notifications@github.com] Ah, but in that case I'd be interested to know more details of what the actual error is, because I'm looking through the DirectSound part of RtAudio.cpp and I don't see what could need anything in mmsystem or mmreg. — |
Ah, yeah, I see. |
This seems like an easy fix. Can someone verify the proposed PR doesn't break anything? Most of us don't have Windows machines. |
I merged #79 because it just adds some header files that certainly exist. Whether this fixes the problem or not I can't be sure. |
I'm closing this, as it should be fixed by the above merge. If a problem still persists, a new issue or PR should be created. |
In certain cases (an MFC app building on Windows 10), RtAudio.cpp pulling in dsound.h (platform copy, as it should be), will fail build.
The solution is to add:
#include "mmsystem.h"
#include "mmreg.h"
immediately before the line:
#include <dsound.h>
I am also aware there is another thread about distributing dsound.h. I don't care about the legal aspect, but it's probably a bad idea. When/if things go wrong, a user will not immediately know which dsound.h was pulled in, especially because <> are used instead of "".
The text was updated successfully, but these errors were encountered: