You are here

QjackCtl 0.2.22 released!

Long overdue but better late than never: QjackCtl, the good old Qt GUI interface to JACK Audio Connection Kit is back on a new latest dot release.

As read from the changelog:

- Fixed default settings for the freebob backend (JACK >= 0.103.0).
- CPU Load status label now says correctly DSP Load.
- The most recently used patchbay definitions can now be correctly selected in round-robin fashion from its drop-down list widget.
- Avoid mixing JACK MIDI ports with regular audio ports on the Connections and Patchbay widgets; strictly list only audio ports.
- Added 192k sample rate to setup settings drop down list (as kindly reminded by Klaus Zimmermann, thanks).
- Most top-level widgets were missing the normal-widget flag, which were causing some sticky size behavior on some window managers.



Hi there!

"I believe that one serious problem is just the complete lack of
documentation about this QjackCtl patchbay thing, other than some rare
notes found while browsing deep some hidden maillist archives ;)"

I came across your comment from 2005 on the PlanetCCRMA mailing archive while searching the net for some "How to" documentation for Qjackctl, and was wondering if you could tell me if the situation has improved?

I've just started looking into Linux audio by installing Ubuntu Studio on a test machine. The installation was seamless and most of my hardware appears to have been detected correctly, but I'm stalled by the lack of a basic introduction to the Qjackctl interface and concept of operation.

I have more than 20 years audio engineering experience, so I don't need need audio concepts explained, but as all of my background involves Windows or Mac DAWs, I do need a primer for Qjackctl. Would you be able to point me to any entry-level documentation for Qjackctl?



rncbc's picture

Aha, you caught me :o)

Badly as is the situation almost remains the same. "Howto" use the QjackCtl's most infamous feature, the Patchbay, has been a dark magic, only secretly whispered to the ears of LADs (cf. linux-audio-dev maillist archives).

As you migh know already I'm not too found of writing user documentation. Damn. This is old programmer dogma. What can I say? Sure, the same old story: no time. And you would ask: so what's the use?

You're right. And guess what? I need (your) help.

In the meanwhile, here follows some gossip about what's last posted to the LA* maillists:

The "Patchbay" window is a place where you declare your intention that some logical connections between some client/ports are to be scanned and maintained active and persistently. There you'll say that you want to keep a connection between two logical groups of ports. When, activated the patchbay code will scan and verify whether each one of the client/port ends are present and then connect those automagically if its the case.

The main purpose of the patchbay is therefore to maintain automatic connections, and _not_ disconnections.

However, there's one little feature that can issue auto-disconnections: that "exclusive" socket flag. When one socket is marked as "exclusive", it will be enforced that _only_ those connections that are declared for that socket will be legal and therefore actively maintained. All other sneaker/outsiders will be immediate and automatically disconnected. This is the only patchbay rule that shall feature implicit disconnections.

Everything else is all about making connections, _not_ disconnections.

If you want to disconnect something, you should do it explicitly in the "Connections" window. Always remember that the "Patchbay" window is not a view of the "Connections", rather just a model.

Hope I have helped somewhat. All this confusion is certainly my own fault, due to a viral lack of documentation ;) Anyway, now you should have a lil'better understanding of how misleading the "Connections" and "Patchbay" resemblance is.

Some (assorted) rules to have in mind:

1) You group all _or_ just a sub-set of ports into a so called patchbay socket. A socket is an ordered group of all or some client ports. You can have as many sockets as you want pointing to the _same_ client, but it is worthwhile to note that having duplicated sockets for the same client with the very same set of ports is just redundant.

2) You declare to connect sockets, not clients. When two sockets are said connected, that is regarded as a declarative rule to automatically connect those respective client-ports, one-by-one in that precise order. Again, the rule states for connecting ports, not just clients.

3) You're probably relying on the bare snapshot that is created while you set a new Patchbay definition. This snapshot is a rough and skewed image of your current client-port connections, that you _must_ regard just as a convenient starting point. Do not take it for granted OOTB. On most if not all situations you'll need to duplicate some sockets, trim each socket port list, reorder, and edit the connections between the intentional port groups (aka sockets).

4) You can edit and add sockets that refer to client/ports that aren't actually running, although it surely helps to get the client/port names right. Client names can be entered as regular expressions while you edit a socket definition. This is most convenient for matching those clients that have some pseudo-random number in their name suffixes (e.g xmms-jack pid).

5) The Patchbay rules are then only effective after you save and activate it.

Please note that the "snapshot" feature it's more like an helper than a solution. You'll most certainly have to edit the resulting patchbay layout anyway, to let it do exactly what you really want.

One thing that may lead to some confusion about this patchbay model is that you're grouping ports (plugs) under "sockets", not exactly JACK clients.

However, one socket maps onto one JACK client, but then you may have several sockets for the same one client. One can see a "socket" as just a way to group JACK client ports in a orderly fashion, nothing more, nothing less.

When you connect an output socket to a input socket, you're telling that you wish their respective ports to be (re)connected whenever actually available, and in a one-to-one order as of each socket.

It might be perfectly possible that the snapshot helper feature doesn't come out with what you really want exactly, specially on some rather complex audio connection topologies--and everybody can come out with one in no time, thanks to JACK again :) The snapshot is however a good start, better than from scratch, or so I thought.

OK. To make all this a little bit clearer, let's suppose you want to maintain the following connections:

   client_1:out_0 -> client_2:in_L
   client_1:out_1 -> client_2:in_R
   client_1:out_2 -> client_3:in_1
   client_1:out_3 -> client_3:in_2

To take advantage of the qjackctl patchbay feature, you must have the following patchbay definition:

Output Sockets

          Client: client_1

          Client: client_1

Input Sockets

          Client: client_2

          Client: client_3

And connect the above as:

  Socket1 -> Socket3
  Socket2 -> Socket4

Remember that, on this patchbay model, you're connecting sockets, not ports. When you connect two sockets together you're actually telling to connect each one of its ports, one by one in order. As you might see, this ordered set is crucial to which JACK ports will be actually connected.

Please check if you try to follow this model as close as you can, when preparing your patchbay. I hope you get it right by now, despite my dubious English ;)

If any doubt still remains, just send your patchbay definition file (.xml) and some clue of which connections you really want. Then I'll be pleased to send back a corrected one to you, if that should be still the case.

rncbc aka Rui Nuno Capela

Hi Rui,

Thanks for posting this information on the Patchbay feature. I was going to take a shot at converting it into laymans terms (or even audio engineers terms ;-) ), but unfortunately I can't get JACK/Qjackctl working on my system, so I'm going to have to postpone my Linux audio adventure until my soundcard(s) are supported.



rncbc's picture

And what soundcard is that?
rncbc aka Rui Nuno Capela

Hi Rui,

The audio device I'd like to use is a Novation Speedio. It's a 2 channel audio/MIDI interface that works fine on XP.

I've been testing Ubuntu Studio. Just installed the beta Real Time kernel. Works perfectly with my onboard via chipset, but can't get rid of the xruns with the Novation. It's not on the list of ALSA supported cards, so I can't see the issue being resolved in the near future.

I suppose I could do the doco using the via, but it would feel kind of strange :D



I'd actually prefer to use the M-Audio FW1814 I have on my main DAW, but it's not supported under FreeBob at the moment.

rncbc's picture

The Novation Speedio is nominally non supported. However, iif it is USB Audio/MIDI class compliant it should work with the standard snd-usb-audio ALSA module. You probably can check that out, as the MIDI interfaces should show up and work alright.

However there probably should be issues with the audio interfaces, like crackling noisy and/or robotized sound ? If thats the case, you can try tweaking settings over the jackd parameters for the alsa driver: try with buffer sizes greater than 128 and with periods no less than 3. Sticking with the nominal 48000 sample rate may help. But these are just shots in the dark.

If that doesn't get things to sound right your audio device is definitively unsupported and will need the vendor (Novation) to agree and open up the technical/proprietary specs and let some smart ALSA developer be ready for the challenge :) Unless someone is brave enough and have plenty of time to do some reverse-engineering over the USB traffic on XP or OSX. Given the business (ie. lack of time) of all those great LADs I don't see that happening anytime soon. Without the manufacturer help most probably it won't happen ever.

rncbc aka Rui Nuno Capela

So I finally gave up and assigned the Novation to the "non-Linux-compatible-hardware" pile, re-installed Ubuntu Studio and the Real Time kernel, and have been trying to get my RME Digi 96/8 PRO running with the help of a Ubuntu Forums member.

The RME is listed as a supported card for ALSA, and Qjackctl sees it and starts the server, but I either get recurring xruns (and choppy sound), or the error message "cannot send request type 7 to server
cannot read result for request type 7 from server (Broken pipe)", depending on what settings I try to start with.

The Ubuntu Forums member noted that JACK was trying to start the session with a 32bit driver, but the RME is a 24bit card, and he suggested changing the word length to 24. When I tried to do this, I noticed that the Word Length option for the RME card under ALSA was not accessible (it appears that it's only accessible when the OSS driver is selected, and then it's only to fixed values of 16, 32 or 64).

Is it possible to set the Word Length for the ALSA driver using Qjackctl?



rncbc's picture

I've found this thread on LAU maillist, which might shed some light into your problem with the RME Digi 96/8 PRO:

just follow the thread until you find the possible solution :)

About the word-length question, yes it's a OSS-only parameter. When using the ALSA backend the driver probes for the available bit-depths 32, 24 and 16bit, in this order, automatically selecting the best for which the driver supports. If 32 bit is supported, it will be set that way. You only have the option to force it to be 16bit, but there's no option for fixing it at 24bit. Anyway, this should be not an issue in your particular case, as the inner ALSA driver module accepts 32bit so, let it be.

rncbc aka Rui Nuno Capela

Thanks for posting this information on the Patchbay feature. I was going to take a shot at converting it into laymans terms (or even audio engineers terms ;-) )

cool Agel i will look forward to your continued comments about this patchbay feature. And thanks for this post this is pretty useful stuff for guys that work with audio.

Add new comment