Linux Network Audio Using JACK

• netmanager Options
• Explicit netJACK2 Address
• Port Connection
• Troubleshooting
  • Test Client
  • Verify Local Audio Output
  • netmanager Options
  • Reloading netmanager
  • Check Audio Presence

There are two JACK-over-network implementations, netJACK1 and netJACK2. The differences between them are described in this FAQ. I chose to use netJACK2 which I think is a better starting point.

netJACK2 is part of JACK2 (at least on Debian) and does not require installation of additional software.

How to use netJACK2 is described in its README here. This walkthrough can also be helpful though I used it as a reference for specific issues rather than following it as a walkthrough.

There are two netJACK2 terms to know: master and slave. Master is the machine that receives the audio over the network and outputs it to the audio hardware. Slave is the machine that sends the audio over the network and that runs the audio-producing applications (e.g. mpv). I will use sink and source instead, respectively, since I think these terms are more clear.

On the sink machine, run:

jackd -d alsa

The explicit launch of jackd is not necessary, as jack_load will start jackd automatically if needed. However an explicit launch may be needed if you wish to adjust jackd parameters, or look at its verbose output (-v option).

Also on the sink machine, run:

jack_load netmanager -i -c

This loads the netJACK2 componentry and gets JACK to listen for network traffic on a predefined multicast address (225.3.19.154:19000 in my case). It also causes the ports to be automatically connected on the sink, meaning audio incoming over the network will actually be routed to the audio hardware. Without the -c option the network connections will be reported as successful but you wouldn't hear any sound output.

On the source machine, run:

jackd -d net

This causes jackd on the source to route the audio to the jackd that is listening on the network on the predefined multicast address.

This is where the README for netJACK2 ends, but if you only go this far you won't have any audio output on the sink to the sound card. For this to happen, the ports need to be connected on the sink machine.

netmanager Options

Since these are awkward to retrieve, here is a copy of them for JACK 1.9.21:

Internal client parameters:
    -a, --multicast-ip      Multicast address (default: 225.3.19.154)
    -p, --udp-net-port      UDP port (default: 19000)
    -c, --auto-connect      Auto connect netmaster to system ports (default: false)
    -s, --auto-save         Save/restore netmaster connection state when restarted (default: false)

Explicit netJACK2 Address

The predefined multicast address works when there is exactly one sink on the network, and avoids having to specify the sink's address to the source in this case. However I have multiple sink machines and thus they need to be configured with explicit addresses:

jack_load netmanager -i '-a 225.1.1.21'

Note that this must be a multicast address, i.e. it can't be the normal unicast IP address of the host machine. I obtained a multicast address by replacing the first octet of the machine's IP address with 225.

To connect to the particular sink, the source executes:

jackd -d net -a 225.1.1.21

Port Connection

One of JACK's features is the ability to set up arbitrary audio routing. While this is beneficial in advanced use cases, it can cause a problem for beginners because netJACK2 by default does not connect incoming network audio on the sink to the audio hardware, resulting in no sound output.

netmanager can perform this connection automatically if it is started with the -c option. Alternatively, the following tools provide more control over the connection logic:

• jack-matchmaker - looks to be mature, unfortunately not packaged for Debian.
• jack-autoconnect - smaller application, looks to be less mature, depends on QT toolkit.

The connections can be verified using qjackctl. The following screenshot shows established connections from the incoming network audio to the audio hardware, if these are not present they can be created in qjackctl by dragging one port to another using the mouse:

Troubleshooting

Test Client

To check that everything is working, you will need a client with JACK output capability. I used mpv:

mpv -ao jack path/to/file.webm

Verify Local Audio Output

Verify that local audio output via JACK is working. I do not use PulseAudio and thus need to send the audio to ALSA. Start a JACK server with ALSA output:

jackd -d alsa

Then use the above mpv command to play something. If you have no sound output, check alsamixer and verify that master and PCM channels are unmuted and have non-zero volume.

I performed the local test on both computers (source and sink) to be used for networked audio.

netmanager Options

netmanager options are obtained by running:

jack_load netmanager -i -h

Note that the output will be printed in jackd console, not in the console that executed jack_load. If you do not launch jackd separately like I have been doing, you may have both outputs in the same console.

Reloading netmanager

To reload netmanager, first unload it with jack_unload:

jack_unload netmanager

Check Audio Presence

I use jackmeter to see whether a port has any audio playing on it. For example:

jack_meter octopus:from_slave_1

jack_meter system:playback_1

This is helpful to determine, for example, that the sink has incoming audio from the network, but this audio isn't rendered to the audio hardware (because the two ports aren't connected, e.g. because the -c option was not given to netmanager).

To see what ports exist on a machine, run:

jack_lsp

To see ports together with their connections, run:

jack_lsp -c