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?