search

jackaudio / jack1

jack1 codebase
Other
250 stars 71 forks source link

Jack error message on Ubuntu #46

Closed CreamyCookie closed 7 years ago

CreamyCookie commented 7 years ago

I'm getting the following message when I use LibGDX with lwjgl3, which uses OpenAl-Soft, which interacts with libjack:

Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock

I get this whether or not I'm playing or initializing a sound. Audio works though.

This is what the OpenAL Soft developer wrote about the issue (when I posted it on their bug tracker first):

Those messages come from libjack, and unfortunately OpenAL Soft can't control them. OpenAL Soft tries to initialize the JACK backend first by trying to connect to a JACK server, in case that's the user's desired output method. If the server is not running, libjack will print that and fail (letting OpenAL Soft try PulseAudio next, then ALSA, etc), but there doesn't seem to be a way to tell libjack that a failed connection isn't a problem and don't print that.

I'm on Ubuntu 16.04. I don't know what else I need to provide, so feel free to ask me about any information you need to fix this.

jdek commented 7 years ago

Depending on whether you want to use JACK or not, you'd either start the JACK server first, or you'd compile openal-soft without JACK. (Also, it looks like openal-soft doesn't use JACK1, it uses JACK2)

CreamyCookie commented 7 years ago

@joshdekock Well, I agree with the OpenAL Soft developers here. There should be a way to "tell libjack that a failed connection isn't a problem and don't print that" error message.

Also, it looks like openal-soft doesn't use JACK1, it uses JACK2

Are you sure? Isn't jack2 still unstable / unfinished?

jdek commented 7 years ago

There should be a way to "tell libjack that a failed connection isn't a problem and don't print that" error message.

Maybe, but you'll have to take that up with the JACK2 people.

And yes, I am sure. JackShmReadWritePtr::~JackShmReadWritePtr is C++ (refers to the JackShmReadWritePtr destructor), and JACK1 is certainly not C++.