Main menu
You are here
Understanding where qjackctl gets start info
HI,
I have always just used qjackctl without messing much with settings.
I actually have a rather extensive customized start on one PC where I start and stop client apps via scripts specified in the qjackctl setup dialog. It's using ffado.
But recently I've been trying to understand whats happening on another system so I started trying to figure out the underlying structure. This system is using ALSA and USB audio.
The question I currently have is:
When I hit the start button in qjackctl on this particular config, it starts 2 system inputs, 2 outputs, and 2 each in/out's for pulse.
But, when I use the command saved in .jackdrc:
/usr/bin/jackd -v -p128 -t2000 -dalsa -r48000 -p16 -n3 -D -Chw:XUSB -Phw:XUSB
only the two system in/out's get created.
In both case, as shown in the connection window of qjackctl.
There doesn't seem to be a mention of pulse in QjackCtl.conf.
So, how does qjackctl know to start the pulse ports? And, how would one duplicate that from the command line?
Regards,
Mac
Re. Understanding where qjackctl gets start info
qjackctl configuration is stored and read from
~/.config/rncbc.org/QjackCtl.conffile.if you have pulseaudio going up (or down) whenever you get jack server running (and what not), then you're probably having it under jackdbus control and then probably never what you may find on
~/.jackdrcwill have any sense to reality, which, as a matter of fact, is a write-only file, as far as qjackctl is concerned--iow. qjackctl do NOT read that file whatsoever, it only writes to it (upon user option).so you probably have been deceived by the jack2 d-bus interface all this time, i suspect, and for that matter, although it may work as one last resort, qjackctl and its author--me, who sticks to jack1 and its command line interface since ever--have no expertise on the whole things that goes under that "marvelous" co-operation that is being done between jack2 and pulseaudio. in fact, as far as jackdbus goes, qjackctl is strictly an one-way interface, that meaning that it only does command it! it doesn't quite control at all what it goes after once the order is spitted out ;)
hth.
cheers
The jack1/jack2 thing may be
The jack1/jack2 thing may be part of my confusion.
I've never been able to find clear instructions as to how to determine which is running.
In this case I'm running whatever is installed with UbuntuStudio 16.04.
As for how the pulse source/sink appears when jack is started. If, pulse somehow is listening for jack to start and connects when it does, then why does the pulse source/sink show up when jack is started from qJackctl, but not when the jack is started from the command line with what is written to .jackdrc... Isn't the command line case just doing the same thing qjackctl is doing?
PS: Another question I have
PS: Another question I have is, sometimes when jack fails to start from qjackctl. From that point on, if qjackctl attempts to start jack qjackctl takes forever to return the first of two errors that essentially say jack wouldn't start. Even after any process related to jack has been killed (i.e. kill pid from the command line).
This persists until the PC is rebooted.
Mac
Re. The jack1/jack2 thing...
as said, you've been confused (well, i said deceived) by jackdbus which has been bundled into jack2, and much to great dismay for all the people that don't give a sh*t to pulseaudio to start with...
in general you tell apart jack1 from jack2 by package name and/or version numbers: jack1 versions are currently tagged as 0.12x.x, while jack2 versions are like 1.9.x .
the
~/.jackdrcfiie is NOT a settings nor configuration file whatsoever--its role is for plainjackdauto-start feature ie. the one that gets executed when some jack client application runs and the jack-server is not currently up and running at the time.problem with many jack2+jackdbus installations is that people fail to understand that the
~/.jackdrcfile is ONLY meaningful tojackdalone; once you get jackdbus into the scene that file is baloney! it won't serve any purpose nor, better said this way, no single part of the jack-audio-connection-kit software will ever read nor write to it. nuff said.from the moment you have jackdbus rigged into the system, it just takes full control and charge of the jack-server auto-starting and what not. also, running
jackdon those environments is simply a masochistic and futile experience: you'll get only pain on every other run; mind you, if you want to have control of the jack-server from the command line, then use `jack_control` as your best bet.hth.
cheers
Add new comment