You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
This feature is not related to any problem, but it is related to efforts to upstream Tenacity's legacy vcpkg fork. In this port is a custom PortAudio port that has two features: jack and asio, which enable the respective backends. By implementing new port features or changes, we can enable JACK by default and introduce a new port feature to allow projects to easily enable ASIO.
I'm aware that you need to provide an ASIO SDK in vcpkg/buildtrees/portaudio/src to get ASIO automatically built, as according to:
# NOTE: the ASIO backend will be built automatically if the ASIO-SDK is provided
Alternatively, PortAudio can automatically download the source as well, which might be slightly more convenient, although that requires CMake 3.18 or later. This can be done if the asio feature is enabled and we have CMake 3.18 or later.
Proposed solution
My proposed solution is simply adding new port features for jack and asio to enable the respective backends. ASIO would be disabled by default due to licensing restrictions while jack would be enabled by default.
Describe alternatives you've considered
Alternatively, for enabling JACK, we can simply modify the port to also depend on jack2 and other appropriate dependencies (i.e., tre for windows | mingw and pthread for windows) and always enable the JACK backend. This might be a more sensible option since PortAudio's JACK backend should work across Windows, macOS, and Linux.
For ASIO, I do not see any other alternative due to licensing restrictions.
Additional context
There is this issue from tenacity-legacy related to getting JACK working on Windows. I believe it was possible and probably happened at one point, but nowadays this isn't possible with modern Tenacity.
The whole intention of making this issue is to discuss a) whether these changes should be implemented, and b) how they should be implemented. I intend to open a PR once we have all of this discussed should we decide to proceed.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
This feature is not related to any problem, but it is related to efforts to upstream Tenacity's legacy vcpkg fork. In this port is a custom PortAudio port that has two features:
jack
andasio
, which enable the respective backends. By implementing new port features or changes, we can enable JACK by default and introduce a new port feature to allow projects to easily enable ASIO.I'm aware that you need to provide an ASIO SDK in
vcpkg/buildtrees/portaudio/src
to get ASIO automatically built, as according to:vcpkg/ports/portaudio/portfile.cmake
Line 14 in 86fba13
Alternatively, PortAudio can automatically download the source as well, which might be slightly more convenient, although that requires CMake 3.18 or later. This can be done if the
asio
feature is enabled and we have CMake 3.18 or later.Proposed solution
My proposed solution is simply adding new port features for
jack
andasio
to enable the respective backends. ASIO would be disabled by default due to licensing restrictions whilejack
would be enabled by default.Describe alternatives you've considered
Alternatively, for enabling JACK, we can simply modify the port to also depend on
jack2
and other appropriate dependencies (i.e.,tre
forwindows | mingw
andpthread
forwindows
) and always enable the JACK backend. This might be a more sensible option since PortAudio's JACK backend should work across Windows, macOS, and Linux.For ASIO, I do not see any other alternative due to licensing restrictions.
Additional context
There is this issue from tenacity-legacy related to getting JACK working on Windows. I believe it was possible and probably happened at one point, but nowadays this isn't possible with modern Tenacity.
The whole intention of making this issue is to discuss a) whether these changes should be implemented, and b) how they should be implemented. I intend to open a PR once we have all of this discussed should we decide to proceed.
The text was updated successfully, but these errors were encountered: