thestk / rtaudio

A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.
Other
1.49k stars 318 forks source link

5.2.0 fails to build on msys2 #340

Closed alex-tee closed 2 years ago

alex-tee commented 2 years ago
../zrythm-1.0.0.alpha.26.0.13.r203.g382885051/subprojects/rtaudio-5.2.0/RtAudio.cpp:2631:46: error: cannot convert 'StreamMutex*' {aka 'RTL_CRITICAL_SECTION*'} to 'pthread_mutex_t*' {aka 'long long int*'}
 2631 |       pthread_cond_wait( &handle->condition, &stream_.mutex ); // block until signaled
      |                                              ^~~~~~~~~~~~~~
      |                                              |
      |                                              StreamMutex* {aka RTL_CRITICAL_SECTION*}

msys2 uses pthreads but I see that this section does #if defined(_WIN32) || defined(__CYGWIN__). there should probably be some detection for msys2 and use pthread if on msys2 even though you are on windows (_WIN32 is defined)

alex-tee commented 2 years ago

actually nevermind I was using meson's wrap from https://mesonbuild.com/Wrapdb-projects.html and it looks like it defines -D__UNIX_JACK__ even on windows

JACK can be used on Windows too btw - I'm not sure why it's not supported in RtAudio

ntonnaett commented 2 years ago

The UNIX in __UNIX_JACK__ is misleading. There's only one flag for JACK in RtAudio.

Did you solve this by disabling JACK support on Windows? It looks like a bug that should be fixed nonetheless. Is MinGW then broken too?

alex-tee commented 2 years ago

I "solved" this by disabling JACK because I already support JACK natively, even on Windows so I don't really need that functionality from RtAudio. I believe building on msys2 is broken if you enable __UNIX_JACK__

garyscavone commented 2 years ago

I haven't investigated using JACK in Windows and I assumed it would require some revisions to get it to work there. But if the JACK code will simply work in Windows without revisions, please let me know. I'm not sure what the issue is with compiling version 5.2. I was recently working on revisions of the JACK API for the newdeviceselection branch I didn't have any problems compiling it, either for OS-X or Linux.

ntonnaett commented 2 years ago

Maybe it's just removing one or two ifdefs against CYGWIN where posix API is used. If build on cygwin the posix API should be used.

falkTX commented 2 years ago

Unless using a wrapper in order to not directly link against libjack.dll, I recommend not having JACK enabled by default. It does work, as Ardour, Bitwig, Carla, Zrythm and others have support for it. The issue is that, for obvious reasons, Windows does not come with JACK installed by default. So an application that links to libjack.dll (say an application using RtAudio with JACK enabled) will fail to start on systems without JACK installed.