Need help with pulseaudio-config?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

146 Stars 17 Forks GNU General Public License v3.0 17 Commits 0 Opened issues


Scripts and notes for custom pulseaudio configuration

Services available


Need anything else?

Contributors list

# 424,176
10 commits
# 457,017
3 commits

This repository contains notes and configuration to set up specific pulseaudio configuration


The objectif is to stream an audio medium to a videoconference, along with the microphone, and while hearing both the audio medium and the videoconference. There are schemas later in this README to explain this goal more clearly.

Also see this stackoverflow issue, which is the main base for this repository.


This was tested on Fedora 25, but should work as well on any distribution using pulseaudio.


It is supposed that you already have a working installation of pulseaudio, launched automatically by your non-root user (default case of Gnome, it seems).

  • Clone this repository :
    git clone
  • Edit the
    script and define MICROPHONE and SPEAKERS to the values of your own.
  • Run the script :
    • If the script worked correctly, there should be a file called
      with a series of five numbers (the ids of the newly created virtual devices).
    • If it didn't, you'll have the error messages from the underlying pactl commands.
  • Configure manually your media source and videoconference input with
  • Enjoy !

If for some reason the script failed or you need to reset the setup simply run

to unload all previously loaded modules.


Here are some good-to-know things, I wish I knew some before starting working on this project : - NEVER use headphones when tinkering with sound. It can be really dangerous, in case of driver malfunctioning, or sudden high volume. - None of this is reboot-proof. You will have to re-execute the script after every reboot. -

pulseaudio -k
restarts your pulseaudio daemon, reloading its configuration. Be careful however, it seems that sometimes it is not enough and makes weird stuff; if you have any doubt, reboot. (Actually,
pulseaudio -k
kills your pulseaudio daemon, but your system should restart it automatically. If not, you can do it with
pulseaudio --start-server
) - Make schemas of what you want to do. Seriously. - By default, pavucontrol may not display everything in its listings, pay attention to the filters at the bottom of the window. - It's probably possible to make these modifications reboot-proof by specifying the configuration in pulseaudio configuration files.

Kinds of PulseAudio devices

Now a few explanations about the different kinds of devices involved. This is only what I have understood experimenting so far, it has no pretention to be absolutely true and flawless. The italicized words are vocabulary that I'm either not sure of, or made up for the sake of clarity. - By "device", I mean either an application connected to pulseaudio API, a driver interfacing a hardware component with pulseaudio, or a virtual device created inside pulseaudio. Pretty much everything that you will see in pavucontrol listings. - A sink is an audio output. - The sinks are listed in the

Output Devices
of pavucontrol. - A sink can receive any number of streams from various players. In this case, these inputs are superposed. - The classic example of sink is speakers, or headphones. - A player is obtained from a device executing some playback, that you would expect to be routed to your speakers by default. - Players appear in the
tab of pavucontrol - The stream coming from a player is directly routed to a sink. - You can select the target sink in the
tab of pavucontrol. - The stream from a player can only be routed to a single sink. - A music player is a good example of such device. - An input is created by a device that is not likely to output to speakers, but more likely to be discarded or routed to another program. - Inputs appear in the
Input Devices
tab of pavucontrol. - The stream from an input in not routed anywhere by default. You have to capture it. - A microphone is a very good example of such device. - A recorder is a device that captures the stream of an input. - Recorders are listed in the
tab of pavucontrol. - In this same tab, you can choose the input they're recording. - A given recorder can only record a single input, but multiple recorders can listen to the same input. - A good example of recorder is a videoconference program, that will both contain a player (for the playback), and a recorder (for sending your own voice through a microphone). - Every sink has an associated monitor. - A monitor is an input, that mirrors the sink it is attached to. - A good example of use is recording you desktop to make a video tutorial. A desktop recording program will likely provide you a recorder, that you can either attach to you microphone (to get your voice), or to the monitor of your speakers (to record the sound emitted by you desktop during the demo). - A null sink is a virtual sink created with the
of pulseaudio. - It behaves like a "real" sink, except that it discards the stream instead of outputing it to speakers (or whatever). - It has an attached monitor as well. - A loopback device is a virtual device created with the
of pulseaudio. - It behaves like the combination of a recorder and an input, relaying the stream from the former to the latter. - Combined with monitors and null sinks, it should allow you to do basically anything you want.


As told above, whenever you're trying to do anything implying virtual devices, make a schema ! I seriously doubt that I would have reached my objective without drawing what I wanted. (And I'm not mentioning my mental sanity)

My convention

For such a situation, I'm convinced that it is essential to pick a convention that prevents you from drawing anything impossible. Here is mine, and the explanations to understand the associated logic : - We can notice that streams can be separated in two categories, depending on where they come from and go : - Come from a player, and go to an output (referred to as active stream) - Come from an input, and go to a recorder (referred to as passive stream) - Each block receives stream(s) on the left, and sends stream(s) on the right - Since every sink always has an attached monitor, they are represented together in a single symbol - If the expected stream(s) on a side are active, the line of this side is doubled - Number of streams : - A tringular extremity does not allow any stream - A trapeze-shaped extremity (cut corners) allows exactly one stream - A flat extremity allows any number of streams (including 0) - Virtual devices are hatched

How to build your setup

Here are the steps I would recommend to follow to build your setup : - Choose your schema convention (if you don't like mine, you can use colors, other shapes, etc ...) - Add all the non-virtual devices that are relevant to your problem (everything that sends or receives streams from pulseaudio) - Make a simple schema to represent what you want to do, without considering constraints of types and number of streams. - Redo it, but respecting these constraints (it's like playing lego, you have to make the same schema as above, but with only certain bricks !) - Try to setup it manually - Create the virtual devices you need (see the script in this repo to see syntax), but without specifying sources, sinks, etc - Route everything according to your schema in pavucontrol - Once it works, automate it by specifying everything at device creation time in a script

My setup

First, a simple schema to explain myself what I want to do :

Then, a schema following the above convention :


These are some of the resources that I found useful when tinkering : - - - - -


Pull requests are welcome, don't hesitate !

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.