Re: [Jack-Devel] Jack Problems

On 3/22/19 11:30 PM, liebrecht(a)grossmann-venter.com wrote: 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. 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