[Jack-Devel] Suggestion to include loopback capability in a Jack session

Hi Jack-devel,

This time it's not an impossible-to-reproduce bug, but a feature request!
Let me know it there's a better place to post this. I think similar things
have been suggested before, but this idea for a 'loopback' client hasn't as
far as I'm aware.

A loopback Jack client to intercept streams to and from partially
Jack-aware programs such as SMPlayer and Firefox would be useful. Both of
these programs output audio to Jack, but only to the system ports, which
makes routing the audio inconvinient. My setup includes a Jack client for
pre-speaker processing (called "Apps Out"), which reduces the audio by 35
dB and applies EQing, so any unexpected connetions directly to the system
ports are inconveniently loud and muddy. Even if these programs gain
support for changing their default output ports, there may be other
programs that won't.

The ALSA loopback device effectively pretends to be hardware, so most
ALSA-aware programs will be connected by default to Apps Out (and its
counterpart "Apps In"), as there is a persistent connection between these
clients and the ALSA-Jack bridge. Some way of configuring a Jack session so
that programs would think that Jack's hypothetical loopback client is the
system capture/plackback - with the real system capture/playback appearing
to be a non-system client - would solve everything. Like adding a monitor
strip for use between the apps and the hardware.

Failing that, is there a way I can force partially Jack-aware programs to
use the ALSA loopback device instead of Jack, maybe by hiding Jack's
existence?

 - Tom

1483154791.13725_0.ltw:2,a <CAPktVFnUxC6HCTrVsAm55mgE25sRZUX-nw3atwWMDyuJe-rXwQ at mail dot gmail dot com>