ability to compile libsoundio source with MSVC

[andrewrk]

@hotgloupi says

What is the use case for compiling libsoundio with visual c++?

Well, there can be many use cases for the users:

• Seamlessly build libsoundio as part of the project
• Honor the build variants (threading mode, debug mode, static vs dynamic
  runtime, debug runtime mode)
• Being able to compile the HEAD in a windows environment (without waiting
  for an external cross-compiled binary)
• Using the VS debugger
• Being able to hack libsoundio in VS (like to make Windows store
  friendly, or to build for IOS/Android from VS, etc.)

There might be more advantages, I'm not a windows guys, but I know that
many multimedia guys are working / targeting a windows environment.

Stating that the project only compiles using gcc will stop many windows
users to use/contribute to libsoundio.

That being said, I will make it compile on visual c++, I was only asking
for some guidance, even if my work won't ever be merged back.

[andrewrk]

Your arguments are convincing. Let's see how much effort it will be to get libsoundio to compile with MSVC.

[hotgloupi]

#50 pull request is one way to do it: leveraging on the STL implementation of the <atomic>

Another way might have been to maintain a compatibility layer for stdatomic.h, but:

• we might introduce bugs in the process (harder that a thin wrapper)
• it would add the burden of maintaining it on libsoundio
• @andrewrk previously argued against it in compat: Add stdatomic.h for old compilers. #48

[jmansion]

Even if one were not so keen on MSVC - wouldn't it be 'better' to use fewer gcc extensions?

You're part way there with cmake already.

The array indexed initialisation seems to me unnecessary though. I guess it can be hidden in a macro and used as documentation. Does clang support it?

[andrewrk]

Even if one were not so keen on MSVC - wouldn't it be 'better' to use fewer gcc extensions?

@jmansion what GCC extensions am I using?

The array indexed initialisation seems to me unnecessary though. I guess it can be hidden in a macro and used as documentation. Does clang support it?

It's part of the C99 standard.

Yes, clang supports it, and I agree that while the feature is helpful to avoid programmer mistakes, the feature is unnecessary. As discussed in the PR, we're removing array indexed initialization to allow building with MSVC.

[jmansion]

I have the libraries and some of the executables building. sio_list_devices has built but only found dummy devices, CMake has wasapi selected.

And bizarre:
C:\src\libsoundio-1.0.3\build\Debug>sio_list_devices --backend dummy
Invalid backend: dummy

So far:

• deal with attribute(x)
• deal with array initialisations in C++ code
• unistd.h and sleep in sio_record
• unit_tests want to link with libm
• lots of PKEY_* duplicate definition issues, some linkage issue there
• soundio_shared link fails for wasapi becuase its looking for a bunch of IID_ symbols.

Possibly the last of these relates to most MSVC using __uuidof and the gcc-ised headers make up for this with explicit support somewhere? No idea about gcc on Windows for building COM stuff, I'm afraid. Given that __uuidof looks like a macro, there is some hope I guess.

Ah, when I looked up the array init, it was marked as a gcc extension. The code that is using it is C++, are you sure its legal?

I wouldn't know about C99. :-( I use gcc for C++ on Linux in dayjob, and use VC++ generally on Windows. I find MS' attitude to C(( indefensible, but at least they are making an effort now.

[jmansion]

That's attribute(x)

[andrewrk]

@jmansion are you aware of #50 ? @hotgloupi has fixed many of these issues already.

It's not quite done yet, but after that pull request we expect to be able to build with MSVC.

[andrewrk]

And bizarre:
C:\src\libsoundio-1.0.3\build\Debug>sio_list_devices --backend dummy
Invalid backend: dummy

You found a bug in sio_list_devices. Fixed: aef8d16

[jmansion]

@jmansion are you aware of #50 ?

I guess not - I came via the 1.0.3 release.

I should move to master I guess. It wasn't my intention to get embroiled in dev - I had been trying rtaudio today and found the performance with wasapi wasn't as good as ASIO, and I was hoping I could kick the tyres and see whether it was any better.

My understanding is that exclusive mode with input and output to the same device should be possible to have sample perfect and similar performance (in terms of over/underrun).

Has to be said that rtaudio with ASIO seems fine with my Asus STX card though.

[andrewrk]

Once 1.1.0 is released (with MSVC compile support), may I invite you to come back and kick the tyres once more by posting in this thread?

Alternately you can download one of the prebuilt Windows builds from http://libsound.io/. I tested them with MSVC.

[andrewrk]

Thanks to @hotgloupi's work in #50 which I just merged, libsoundio source code can be compiled with MSVC. However it does not work out of the box, since the cmake configuration isn't quite set up for an MSVC build. So the remaining work to be done on this issue is edit the cmake configuration so that MSVC build can be performed on Windows.

However, at this point it is quite possible for someone to directly embed libsoundio in their msvc project.

[kritzikratzi]

i managed to at least compile the dummy interface.
i have zero experience with cmake, but here's what i found out:

1. msvc doesn't like some gcc flags. instead of this https://github.com/andrewrk/libsoundio/blob/master/CMakeLists.txt#L197-L200 i used:

   if(MSVC)
       set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /Wall /W4")
       set(LIB_CFLAGS "/TP /Wall /W4")
   else(MSVC)
       set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -Werror -pedantic")
       set(LIB_CFLAGS "-std=c11 -fvisibility=hidden -Wall -Werror=strict-prototypes -Werror=old-style-definition -Werror=missing-prototypes -D_REENTRANT -D_POSIX_C_SOURCE=200809L")
   endif(MSVC)
   

2. there is no libm in msvc https://github.com/andrewrk/libsoundio/blob/master/CMakeLists.txt#L248
   to test i just removed all the ms :)
   (i guess clang/gcc still needs those)

[kritzikratzi]

ps. i forgot: i also added a #include "list.h" to sound_private.h

[hotgloupi]

@kritzikratzi I'm not sure you need to include "list.h", do you remember what was the error ?

Also, with this setup, one cannot choose to compile using gcc or clang in C++ mode, which could be a valuable thing to allow.

@andrewrk It could be a good idea to setup some automated build on Travis and appveyor, I can provide some help if needed

[kritzikratzi]

@hotgloupi about the gcc/clang problem: the only thing that needs to be taken care of is libm (either adding it for clang/gcc only, or removing it for msvc. not sure whats easier).

the list.h problem came from here these two lines:
https://github.com/andrewrk/libsoundio/blob/master/src/soundio_private.h#L112-L113

[hotgloupi]

My point was: Allowing compilation in C++ with clang/gcc is kind of a good idea, as it highlight dangerous cast or other type checks warnings (as C++ has stricter rules).

About the list.h thing, I understand now that you were only compiling the dummy backend. If any other backend is enabled, I guess it will somehow include list.h. That's why I didn't see the problem while playing with MSVC.

[andrewrk]

@andrewrk It could be a good idea to setup some automated build on Travis and appveyor, I can provide some help if needed

I've considered this. The problem is that testing libsoundio is really only effective when testing on various hardware with different sound cards. Setting up a Travis/appveyor build would be misleading - looking like tests were passing when really things could be horribly broken for many hardware configurations.

[kritzikratzi]

@andrewrk about the travis builds: it's still a good baseline to know it works on various compilers. for manual testing i'm happy to help whenever i have time. (i usually have a mbp and lenovo with win8 plus external soundcard nearby). feel free to send emails before releases.

[andrewrk]

@andrewrk about the travis builds: it's still a good baseline to know it works on various compilers.

Fair point.

for manual testing i'm happy to help whenever i have time. (i usually have a mbp and lenovo with win8 plus external soundcard nearby). feel free to send emails before releases.

I plan to release 1.1.0 soon - now is a good time.

[hotgloupi]

@andrewrk The only point of automated builds is to see if it builds on all compiler/os selected.
It can also generate release builds when a tag is pushed. Adding (relevant) tests is completely optional, but I am positively sure that some unittesting cannot do any harm. As for doing proper testing, it seems possible but rather complicated, maybe with qemu ?

[jmansion]

I plan to release 1.1.0 soon - now is a good time.

Any idea when the release will be made?

[andrewrk]

@jmansion if not released by Feb 1, I invite you to remind me by posting in this thread again.

[andrewrk]

I'm going to do my own tests here with a virtual machine, but @michaelmaltese what's the status of this issue last you checked? Did you ever get all the way to a working MSVC build?

[jacquesh]

I can confirm that it builds with MSVC, though you do need to turn off warnings-as-errors (it gives quite a few warnings).

[peeeeter]

Just thought I'd poke this thread for status. It seemed like MSVS was originally targeted for 1.1.0, but now maybe 1.1.1?

I agree that MSVS support is cool for just quick and dirty getting going and kicking the tires. I actually use MinGW for windows almost exclusively for my own projects, but its sometimes challenging to get foreign projects going for the first time with gnu/msys on windows, so its nice to just try things out in msvs before putting in the effort to unify the gnu on windows builds.

I'm really sold on the "vs portaudio" wiki page which rang true for me - thanks for putting together this project!

[mdsitton]

Well I modified the CMakeList.txt then had to rearrange a couple windows header includes, and got it building(under c++) for my project.

[peeeeter]

Okay. Since some mods were required, I guess that's why this issue isn't fully closed yet.

[mdsitton]

All of the changes are in wasapi.c/wasapi.h/CMakeLists.txt, though i was working from 1.1.0 I might try again with git master here soon and see if anything is different.

[andrewrk]

I left the issue open because I haven't personally tested this with MSVC yet. Will do soon...

[lamarqua]

If anyone has clear instructions on how to build with either VS 2015 or VS 2017 I'd gladly take them...

[larschristensen]

Does anybody know if it is possible to even use libsoundio in a project with MSVC currently or is it only possible with MinGW? Since there is no .lib or .def library files generated for Windows use, I can't see how this can be used in a MSVC project. However, if a .def file was generated as part of the build procedure, I think it should be possible. If anybody has a solution to this, please let me know.

Edit: It turns out that a .dll.a file can be used in the same way as a .lib file, so the prebuild library can be used directly in a MSVC project.