Re: Jack Problems

On Fri, March 22, 2019 5:30 pm, [email protected] wrote:
> Who are the experts that will be using Jack.

If you search through the linux audio users mail list archives you will
find plenty of posts with help for new users of jack.
But as you say:
> [doesn't] deserve any criticism other than usability for newcombers

That is a valid complaint.  The problem is somewhat difficult to solve,
partly because the problem being solved is complicated, partly because on
most linux distributions the default audio  configuration is set for
playing back audio, not producing audio.

> By large 95% of users complain about jack.

Do you know why those users are using jack?  Ardour has supported using
ALSA directly for quite a while, I believe Qtractor and LMMS do as well. 
Do those users need the ability to route between applications which jack
provides?

> If I can find some of these experts it will go a long way to figure out
> how to actually use it in reality. But I found none on the 10s of
> usergroups related to audio that I subscribe to.

10's of usergroups?  Did you start with linux-audio-users?  That is the
primary location for audio on linux information.

> about jack. I myself have been using Linux since 97 and did a lot of
> unix and assembler programming before 97.

I am actually a little surprised to find you have been using linux for so
long, there was a lot of basic information missing in your original email
which I would expect an experienced user to provide out of habit.
For example, your first email did not specify
- which operating system you were using (jackd runs on 3).
- later you indicated linux; which distribution?  Which version?
- which version of jackd and pulseaudio?

You provided partial information from qjackctl:
qjackctl reports the following.
Cannot connect to server socket err = No such file or directory
...

But did not provide the full output of the "Messages" window of qjackctl.
For example, when qjackctl attempts to start jackd you should see the full
command line which is used:
19:22:09.341 JACK is starting...
19:22:09.341 /usr/bin/jackd -P70 -t2000 -dalsa -dhw:Lambda -r48000 -p1024
-n3 -zt -I376 -O376

The output of jackd follows from there.  "Cannot connect to server" type
messages are common as jackd initially starts.

You can also copy that command line and start jackd from a terminal so
that you can see the startup messages being printed in real time.

> I am hesitant to use jack as it almost never work consistently,
> pulseaudio at least works.

That is probably part of the problem.  The way that pulseaudio ensures it
works is starting early and locking exclusive access of the primary ALSA
device.  Recent versions give up control gracefully, for many years now on
Fedora I have had no problems at all starting  jackd with either qjackctl
or from the command line, the version of pulseaudio shipped by fedora
gives up control of the audio device when jackd requests, and when I stop
jackd then pulseaudio takes control again.  Knowing which distribution you
use may make it easier for someone to help.  Ubuntu typically breaks audio
production software frequently, but there are optional repositories to
help with that.

> it is difficult for me to
> understand jack as it has no consistent specification

I am not sure I understand this complaint.  Do you have an example of
something in the man page or help output you find inconsistent?  The
different backends available and the way that there are arguments to the
main jack server and separate arguments for the backend driver can be
confusing.  Is that what you are referring to?

> what is the exact mechanism by which pulse
> interfere with jack

The pulseaudio server will open an ALSA device for exclusive access, but
jackd also needs to open the ALSA device for exclusive access.  Obviously
only one server at a time can have exclusive access to a particular
driver.   Most modern versions of pulseaudio that I am familiar with using
on Fedora Linux do not have that problem, but as you gave no indication of
which linux distribution, which pulseaudio version, or which jackd version
you are using it is difficult to say more than "works for me."
jack-audio-connection-kit-1.9.12-6.fc29.x86_64
pulseaudio-12.2-1.fc29.x86_64
qjackctl-0.5.5-2.fc29.x86_64

> As I understand it jack should be an either/or/add
> switch for audio streams

I do not understand exactly what you are trying to convey.  I think of
jackd more like a patch bay for routing audio within the OS.  Is that just
a different way of saying the same thing you wrote there?

> I found that jack seemingly does not really do direct hardware access

Of course not, it has been a principle of general purpose operating
systems for well over five decades that user space programs do not 
directly access hardware, the operating system kernel mediates access to
the hardware.

> which further complicates things

On the contrary it simplifies things.  It would be wasteful and error
prone if the jack project had to duplicate the work done in the linux
kernel audio drivers.  It also gives a clear boundary to check basic audio
functionality using ALSA utilities (such as aplay and arecord) separately
from the routing and patch bay functionality of jackd.

> If it in principle rely on alsa then those interfaces needs to be
> very well documented how it communicates with
> alsa, what the exceptions and conditions are etc.

ALSA has an API, jackd also has an API, but I don't get the impression
that is what you mean.
The method that jackd uses to communicate with ALSA devices is the same as
every audio software which supports ALSA, including pulseaudio, audacity,
Ardour, etc.  I am not really sure what you mean there, perhaps copying
the actual output from jackd when it has an error will allow someone to
help you by pointing out the messages which indicate why jackd could not
start.

> if there was e.g. just a hard patchbay application that would replace
jack I would
> use it in an instant. It would not be elegant but would clearly route
> signals by hand.

That is basically what jackd is.  Having multiple audio interfaces
complicates the situation, having multiple sound servers (e.g. jack and
pulseaudio) complicates the situation.  If you have a machine with only
one audio interface and no other audio servers running just start jackd
and it will work.  Once your  machine setup gets more complicated than
that then any sound server will require you to make some configuration
choices.

One thing which may in the future prove useful to you is the Red Hat
pipewire project.  The aim of that project is to make a single server
which combines the features of pulseaudio and jackd, and also provides
similar features for video, running as the default media server for
Fedora.  That final working solution is still some time in the future, but
sounds like it should be what you are looking for in terms of default
working setup with only minimal configuration required.

> That is maybe what is needed until jack becomes user friendly

I am reminded of a quip about Unix operating systems: "Unix is user
friendly, it is just very picky about who it makes friends with."

> Isnt there at least some for of user debug frontend for jack that can
> point to the errors

Start jackd from the command line, copy and paste the output messages to
an email so that someone can have hope of helping you.  So far you have a
lot of complaints but not much information.

Regarding the question you asked of Holger:
> How is that going to influence my abilty to use audio interfaces as now
> alsa wont be able to access the usb ports directly when I follow the
> link advice you included in your message. If I understand it right

No, you misunderstood what the instructions were doing.  They were
essentially making sure pulseaudio did not  start automatically, setting
up jackd as the  main audio server, launching pulse with the jack
interface module as the audio interface instead of ALSA, and also
secondarily setting up an ALSA pseudo-device which exposed a jack port as
an ALSA device for software which attempts to use ALSA directly.  I find
that almost all current software versions support pulse, so the ALSA setup
is not needed.

Note that in my opinion if you need those instructions, your chosen linux
distribution has not done a good job configuring the audio software
provided in the distribution repositories.  I don't want to be too
repetitive, but in Fedora none of that is necessary, just start jackd and
it works.  You will probably need to load the jack modules in pulseaudio,
but that may work by default now. I am not sure, I have had a modified
pulse configuration file in my user directory for so long I am not
positive of some of the current default behavior.

-- 
Chris Caudle