A Weird Imagination

Virtual microphone using GStreamer and PulseAudio

The problem#

My previous post got the video from my smartphone to show up as a camera device on my desktop, but for a video chat, we probably also want audio. So, now the question is: how to build GStreamer pipelines that will allow minimal-webrtc-gstreamer to use virtual microphone and speaker devices that I can point a voice/video chat application at, allowing me to use my smartphone's microphone and speaker for applications on my desktop.

The solution#

The following requires that you are using PulseAudio as your sound server and have downloaded minimal-webrtc-gstreamer:

pactl load-module module-null-sink sink_name=virtspk \
    sink_properties=device.description=Virtual_Speaker
pactl load-module module-null-sink sink_name=virtmic \
    sink_properties=device.description=Virtual_Microphone_Sink
pactl load-module module-remap-source \
    master=virtmic.monitor source_name=virtmic \
    source_properties=device.description=Virtual_Microphone
./minimal-webrtc-host.py\
    --url "https://apps.aweirdimagination.net/camera/"\
    --receiveAudioTo device=virtmic\
    --sendAudio "pulsesrc device=virtspk.monitor"\
    --sendVideo false --receiveVideo false

You can reset your PulseAudio configuration by killing PulseAudio:

pulseaudio -k

You can make the PulseAudio settings permanent by following these instructions to put them in your default.pa file.

The details#

Read more…

PulseAudio headphone jack troubles

Posted in

The problem#

Since I got a new motherboard (and therefore new audio hardware as I'm using the basic one built into the motherboard) sometimes after I unplugged my headphones, my speakers would not output any sound.

pavucontrol showed the only available output as "Built-in Audio Digital Stereo" with a port of "S/PDIF", which does not describe any audio device I had ever used. If I plugged my headphones back in, they would work fine, and usually after unplugging and plugging back in my headphones enough times, my computer would eventually acknowledge that my speakers were connected by showing the expected "Built-in Audio Analog Stereo" with a port of "Line Out".

The solution#

In /usr/share/pulseaudio/alsa-mixer/paths/analog-output-lineout.conf change

[Jack Front Headphone]
state.plugged = no
state.unplugged = unknown

to

[Jack Front Headphone]
state.plugged = no
state.unplugged = yes       # changed from unknown

This forces PulseAudio to consider there to be speakers plugged into the "Line Out" port, so it may cause strange behavior if that is not the case.

To apply the change, run

pulseaudio --kill
pulseaudio --start

to restart PulseAudio.

Read more…

Volume via shell

Posted in

The problem#

Sometimes a GUI is not the best way to control a computer's volume. Usually if you care about the volume of your computer, you're probably nearby but perhaps would rather be using a remote or other shortcut way of changing the volume. The specific use case that prompted this blog post was binding the volume up and volume down keys on my keyboard to the global volume control (as opposed to separately binding them in each application).

Read more…

Application bypassing PulseAudio

Posted in

The problem#

Recently I ran a game1 and instead of the expected music, got distorted noise. At first I thought there was something physically wrong with my speakers or the connection to them, but running any other program resulted in normal sound, albeit mixed with the distorted sound of the game. Even more strangely, changing the volume in the game changed the volume of the distorted noise, implying the game was in fact generating the right thing but it was being misinterpreted, so the culprit was neither the game nor the sound driver but somewhere in between them.

As I had recently set up PulseAudio2, I suspected it was to blame. I opened up pavucontrol to find the game omitted from the list of applications producing sound, which suggested the problem was caused by the game trying to use some way to produce sound that PulseAudio was not capturing.

The solution#

The short version is that the problem was solved by restarting PulseAudio:

$ killall -9 pulseaudio

Read more…

PulseAudio

Posted in

PulseAudio is what most modern Linux distributions use as a sound server, the part of the sound subsystem that sits between applications and the sound driver supporting features like allowing multiple applications to output sound simultaneously. PulseAudio adds various features not present in other Linux sound servers like per-application volume controls and easily outputting to different audio devices (for instance, using HDMI audio instead of the normal audio jack).

PulseAudio can be controlled using pavucontrol, which is a GUI audio mixer. It shows a volume meter and control for every application producing sound as well as an option to choose which audio device it is outputting to. It additionally lists all of the hardware input and output devices, as you would expect from an audio mixer.

Fixing problems#

Restarting PulseAudio#

If PulseAudio is not working properly, you can restart it by running

$ killall -9 pulseaudio

No, really, that's what Debian's PulseAudio page says to do.

When I initially installed PulseAudio, it didn't have my sound cards listed and just had the default null outuput, making it not very useful. Running that command to restart it fixed it.

Muted devices#

PulseAudio seems to mute my sound card all by itself. Currently, I just go into pavucontrol and unmute it.

Detachable X sessions

X forwarding#

Normally with X, it's easy to run an application on a remote computer just by using X forwarding:

local:~$ ssh -X host
host:~$ echo $DISPLAY
localhost:20.0
host:~$ xterm

The xterm will appear on your local computer.

But if you want to continue working with that application on a different remote computer (or once you are physically in front of the computer it is running on), then you're out of luck.

For an application running in the terminal, you can start it inside a GNU Screen (or tmux) session which you can detach and then attach to again on another ssh connection.

GNU Screen for X#

xpra (X Persistent Remote Applications) lets you move graphical applications from one computer to another in addition to fixing other problems with X forwarding. If you instead use xpra for the forwarding, then you can detach and reattach to the session at will.

Read more…