Pipewire can be used to handle (almost) all audio routing between radio software on Linux. This approach can be easier to configure and less brittle than using ALSA, which often requires establishing several virtual “mixer” devices as ALSA applications otherwise like to take direct control over the sound card.

Of particular note: on a system fully configured to use Pipewire and the Pipewire-ALSA plugin, the “pipewire” device can be used as both ALSA source and sink, allowing otherwise ALSA-only software to behave as otherwise ordinary Pipewire clients. For example, Direwolf can be configured as a Pipewire client by configuring ADEVICE as “pipewire”:

#...
ADEVICE pipewire
ACHANNELS 1
ARATE 48000
#...

Other software, like qsstv, fldigi, and wsjtx may all be similarly instructed to use the “pipewire” device to appear as a Pipewire client. Then, software like pavucontrol may be used to adjust volume levels and what sound card each application uses.

There is one caveat. A Pipewire-ALSA client typically declares its own name. If you have several direwolf instances running, such as in the case of multiple radios or even FX.25 and IL2P in the same passband, there will be no way to disambiguate which client is which. Therefore, they cannot be (reliably) configured to use a specific sound card or specific volume levels when using the same name. The solution is to use the PIPEWIRE_ALSA environment variable to override parameters of the Pipewire-ALSA plugin. For example,

~$ PIPEWIRE_ALSA='{ node.name=direwolf-ic7300, application.name=direwolf-ic7300 }' direwolf -c direwolf-ic7300.conf

will ensure that this particular direwolf instance will be named “direwolf-ic7300”, which could be used to disambiguate it from a “direwolf-ic7300-il2p” or a “direwolf-ftm150”.

In a systemd service, environment variables may be set using the Environment= option:

#...
[Service]
#...
Environment=PIPEWIRE_ALSA='{ node.name=direwolf-ic7300, application.name=direwolf-ic7300 }'
#...