Project

Name: netjack_at_LAG
People: cassette
Description: netjack at lag

netjack_at_LAG

Some basic principles

Netjack is a driver for jack. Ordinarily, jack uses the alsa driver. This means that attaches itself to a physical sound-card. Using the net driver, it attaches itself to a network.

To understand netjack, it is helpful to really focus on the fact that all it does is creates sources or sinks (inputs or outputs) on the client and server computers for sound to travel over the network. It does nothing more.

When using the alsa driver, the system_out ports send audio to the sound-card physical output ports. When using the net driver, the system_out ports send audio to the network. The server then routes the audio however it is setup. In other words the audio comes into the server and then it could be recorded, sent through effects, or simply sent to the server sound-card physical outputs.

Audio cannot be sent from the server to the client. There might be a really hacky and crazy way to do this using the client also as a server and the server as a client and then moving the audio between the jack daemons on the same machine (e.g. the actual client) using ALSA loopback devices but netjack has NOT been designed at present to have bi-directional audio.

It is really important that the server is started before the client is!

Overview of basic procedure

Most of the key information is here.

start jack on the server
run jack_load netmanager on the server from a terminal
start jack on the client from qjackctl using the net driver; or run jack from the command line using jackd -R -d net (real-time with net as driver)
on the client, connect the sound sources through the qjackctl interface “Connect” to the system output.
on the server route the audio from the input which is named after the client computer to the destination

Sending computer (client)

It is really important that the server is started before the client is!

It is possible to have multiple clients going to one server. This could be a lot of fun for collaborative audio madness!

Netjack does not use the client’s sound-card. This is a key point to remember. You could think of it as using the ethernet card as the sound-card.

To start the netjack client you can start jack on the client from qjackctl using the net driver; or run jack from the command line using

jackd -R -d net

The -R flag is to set as real-time. There are some other flags in the documentation which could be interesting like running things in synchronous mode etc.

The netjack driver uses multicast (I think) to find the server on the local network – anyway it does it automatically. So it should just connect; however, there are commands to direct to a specific server (for example if you wanted to run multiple servers on the same network). See the documentation. on how to send to a specific port.

More ports?

You can add --output-ports=X to the command line or put that in the field called “Server Suffix” under qjackctl->Setup->Settings->Advanced. More ports lead to more bandwidth on the network.

At one point I had 8 channels of audio running from a very low memory laptop over wifi and there were a few xruns but it was almost usable. Had it been an ethernet cable maybe it would have worked fine. See below on ‘latency issues’.

Using USB radio receivers

At one point running 4 ports over netjack with 3 radio receivers connected to them over ethernet, we were having a lot stuttering and xruns. There are a number of possible problems for this:

It is possible that the client computer was not able to put audio on the network fast enough
The usb audio radio receivers were using too much of the real-time cpu cycle to get the audio to then move it through
The radio receivers only send audio to fucking pulseaudio. There is a way to move audio from pulseaudio into jack but it probably involves re-sampling which adds to the cpu load.
We were also fiddling around with superlooper as an intermediary layer so that probably also added to the burden on the cpu.

Physical input on client to netjack

Given the limited space at the lab, it almost worked to setup a mixer elsewhere in the space and then send the audio over the network to the computer that is plugged into the speakers. Therefore other devices could setup on another table and drone away with everyone else or whatever. Whether a way to have MIDI sync could be found is an open question at the moment... This could be a nice way to record the beast more often (e.g. it does not need to be dragged around, just a laptop with a soundcard needs to be present).

To understand the rationale of the following, you have to remember that the jackd net driver does not actually attach itself to any sound-card. Therefore, there is no actual input ports that appear when jackd with the net driver starts up. You will see some input ports, but given that netjack is not suppose to be bi-directional, I really do not know what these are but anyway you cannot get audio from the sound-card on them that is what I know...

To have audio come in from the sound-card on the client, you have to run in an terminal:

alsa_in hw:0

This will create an input port in the Connect screen in qjackctl. You can then route it to whatever – e.g. effects on the client or directly out to the server.

The name hw:0 is the name of sound-card from which you want input. Normally it will be hw:0. To see all the physical sound-cards that the computer sees type:

aplay -l

Some sound-cards have multiple interfaces to they are named hw:0,0 and hw:0,1. The naming and numbering comes from ALSA kernel modules and commands and it can be an absolute beast to understand and debug. From some multi-channel devices ALSA creates multiple devices, for others it creates only one.

There is also something in the documentation about using jack_load audioadapter

But I have not yet worked with it to see how it works. It seems to do more or less the same thing – e.g. make the client sound-card appear as ports.

Receiving computer (server)

On the studio computer it seems like somehow the ordinary jack service is including the netjack module but ordinarily once jack is started you run jack_load netmanager in a terminal and it the server should be read for netjack client connections.

Perhaps it was because the module was already loaded but I was able to load the module this even when the same computer was broad-casting through OBS (e.g. it did not stop the audio or cause a glitch).

Incidentally, it is possible to have the server listen on a different UDP port. See the documentation on how to do this.

At one point with testing, we had to take down the iptables so that the client could find the server. This can be done as root with iptables -F.

Latency issues

On the official documentation there is some discussion about jack buffer size and network MTU and its relationship with latency and how the buffer sizes between the client and server have to be matched etc. I have not had a chance to play around with this, but for some applications it may be needed to ensure that there are no xruns.

Metering and troubleshooting

Once you have one side of the interaction setup you move to the other computer with the assumption that one side of the connection is good and try to trouble shoot the other side.

I have found it helpful to run ebumeter (which is a jack compatible graphical meter) to monitor whether audio is present before sending out to network or alternatively arriving on the server before trying to figure out what to do with it on the server.