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
In GNU Guix we're building all packages that have support for JACK with jack1. When a user has JACK2 installed, however, these applications will attempt to connect to a non-existent socket, such as /dev/shm/jack-1000/default/jack_0.
It is possible to connect only by overriding the used JACK library with LD_LIBRARY_PATH, which is inelegant.
Is there a way to let JACK2 create the same sockets that JACK1 applications expect?
The text was updated successfully, but these errors were encountered:
Are you perhaps trying to use libjack.so of JACK1 while a JACK2 server is running?
Because if so, this is completely unsupported. the JACK client libraries must match the server.
Yes, the applications are all linked with libjack.so of JACK1 (and RUNPATH is set so that this specific variant of libjack.so is found at runtime). I suppose there's no other way than to override the libjack.so at runtime then.
As a distribution we cannot know what variant of JACK a user will install.
Not sure if I fully understand, but if the application is using libjack.so from JACK1 while the user is running JACK server from JACK2, this can never work.
Not even updates of the same JACK (1 vs 2) are guaranteed to work. For example, on the latest release of JACK2 I bumped the maximum number of clients and ports. This breaks the server-side data structures, so libjack.so from 1.9.13 cannot talk with jackd from 1.9.14.
You need to have client library and server versions match. Anything else is unsupported.
In GNU Guix we're building all packages that have support for JACK with jack1. When a user has JACK2 installed, however, these applications will attempt to connect to a non-existent socket, such as
/dev/shm/jack-1000/default/jack_0
.It is possible to connect only by overriding the used JACK library with LD_LIBRARY_PATH, which is inelegant.
Is there a way to let JACK2 create the same sockets that JACK1 applications expect?
The text was updated successfully, but these errors were encountered: