[Jack-Devel] Jack Problems

Jörn Nettingsmeier nettings at stackingdwarves.net
Tue Mar 26 14:34:41 CET 2019


On 3/22/19 11:30 PM, liebrecht at grossmann-venter.com wrote:
> Dont want to sound disrespectful, but I need to ask.
> 
> Who are the experts that will be using Jack.

Does having deployed multichannel (sometimes massively so) JACK systems 
for more than 10 years count?

I guess you need to get a fresh perspective on problem solving under 
Linux. It basically boils down to understanding how a layered system 
works, and testing and verifying the stack from the bottom up.

As long as the word "reinstall" pops up in your mind while debugging any 
problem, you are not here yet.

You start with your sound hardware. There needs to be an ALSA or FFADO 
or alsa-firewire driver for it. Some vendors choose to make life hell 
for you by introducing incompatible firmware updates. That's a problem, 
but it's not a JACK problem. Do some research and see if you can find 
lots of people who are sucessfully using the interface you have in mind 
on Linux, before buying.

When you plug it in, look at the syslog (sudo journalctl -f or tailf 
/var/log/messages on pre-systemd systems). Look at the messages, check 
for errors.

See if you see the device with aplay -L.
See if you can see in in alsamixer or check its controls with amixer.

If this doesn't work, no point complaining about JACK.

If USB, learn about class compliance, and of any limitations the device 
might have in class compliant mode.

Understand JACK basics. JACK does not deal with multiple sample rates, 
and it cannot change sample rate on the fly. To reliably start JACK, the 
sample rate of the device must be _set_ at opening time by the JACK 
backend by saying "jack -dalsa -r 48000" (for example), or, if clocked 
externally, it must be stable and you still need to specify the correct 
samplerate when starting.

Next up: start JACK. Qjackctl does the job just fine and is certainly 
not the root of your problems. Whether you start JACK on the command 
line or with Qjackctl - look at the messages it spits out.

If every your jack dies: look at the error messages. Don't post the 
error messages of some JACK client after your jack server has apparently 
died (or never started up in the first place.
Note the time of JACK dying and correlate that to outputs of 'dmesg', 
and again, the syslog.

JACK is the single most deterministic audio system on the planet. I've 
literally ran JACK systems for months of uninterrupted uptime, and they 
would have run for years if I didn'd update my systems frequently.

> I havent been on an audio related usergroup where anything positive has 
> been said (except largely what I posted) about jack. By large 95% of 
> users complain about jack.

That is not a very smart argument. All it says it that either those 
usergroups are not very clueful, or that JACK solves a problem they 
don't have, and they haven't figured that out yet.

Good luck :)


-- 
Jörn Nettingsmeier
Tuinbouwstraat 180, 1097 ZB Amsterdam, Nederland
Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Tonmeister VDT
http://stackingdwarves.net



More information about the Jackaudio mailing list