My use case is splitting audio into separate channels in OBS for Twitch Streams so I can play music live without getting my VoDs struck. If my approach is entirely wrong for the use case, I’m happy to scrap the whole thing and sign it off as learning experience.
My solution is to use virtual sinks that I record through Audio Sources in OBS. I’ve got two loopback-devices (config at the end) with media.class = Audio/Sink
, assign my playback streams to the relevant output capture.
The loopback of each is then passed on to the common default (physical) output device, namely my headphones.
So far, this has been working great for me, aside from minor inconveniences:
The first is that I want certain apps or playback streams to automatically be assigned to the capture sinks upon starting the app.
I had a working pulseaudio¹ setup on Ubuntu where I used pavucontrol to set the output once per app and it remembered that setting. Every time I opened that app, it would direct its playback streams to that sink.
I migrated to Nobara and opted to try configuring pipewire (directly)² instead. The devices are created correctly but every time I (re-)start a relevant app I have to go set its capture device again.
The second is that occasionaly upon logging in, one loopback stream will initially be passed to the other sink instead of the default output, which resolves upon restarting pipewire³. Is something wrong with my config?
Both have the same target.object
and restarting it fixes it, so I’m guessing it may be some race condition thing where the alsa_output isn’t initialised at startup yet, but I don’t know how to diagnose or fix that
1: I have since learned that apparently it’s actually still pipewire parsing that config, but the point is I configured it through ~/.config/pulse/default.pa
2: ~/config/pipewire/pipewire.conf.d/default-devices.conf
3: Trying to set it in pavucontrol doesn’t work and keeps resetting that playback’s output to the given sink if I try to select the correct capture device. Repatching them in Helvum does the job, but then pavucontrol just shows blank for the device (doesn’t interfere with controlling the volume, but maybe it’s relevant for diagnosing)
My current ~/.config/pipewire/pipewire.conf.d/default-devices.conf
:
context.modules = [
{ name = libpipewire-module-loopback
args = {
audio.position = [ FL FR ]
capture.props = {
media.class = Audio/Sink
node.name = vod_sink
node.description = "Sink for VoD Audio"
}
playback.props = {
node.name = "vod_sink.output"
node.description = "VoD Audio"
node.passive = true
target.object = "alsa_output.pci-0000_00_1b.0.analog-stereo"
}
}
}
{ name = libpipewire-module-loopback
args = {
audio.position = [ FL FR ]
capture.props = {
media.class = Audio/Sink
node.name = live_sink
node.description = "Sink for Live-Only Audio"
}
playback.props = {
node.name = "live_sink.output"
node.description = "Live-Only Audio"
node.passive = true
target.object = "alsa_output.pci-0000_00_1b.0.analog-stereo"
}
}
}
]
For future readers looking to set separate default pulseaudio or pipewire sinks for individual apps, this his how I accomplished it.
If you’re using pipewire config,
sink_name
will be callednode.name
in thecapture.props
of the module.For flatpak apps, I used this per-user override only for my current user:
flatpak override --user --env=PULSE_SINK=(sink_name) (full application name)
For example:
flatpak override --user --env=PULSE_SINK=live_sink com.spotify.Client
For steam games, insert the respective environment variable into the launch options if you already have some, or otherwise put
PULSE_SINK=(sink_name) %command%
in there.Steam Tinker Launch maintains a
gamecfgs/customvars/(Game ID).conf
config file for each game to set custom environment variables in, which you can most conveniently find through from the launcher’s Main Menu > Editor > find the customvars entry. In there, just put the linePULSE_SINK=(sink_name)
and you’ll be good to go.