The Linux Experiment

Sort of a follow up (in spirit) to two of Jon’s previous posts regarding pulse audio loopback; I noticed that there was quite a bit of delay (~500ms to 1second) in the default configuration and began searching for a way to fix it. After some research I found an alternative way to achieve the loopback but with must less delay.

1. Install paman

First install the PulseAudio Manager application so that you can correctly identify the input device (i.e. your mic or line-in) and your output device (i.e. the sound card you are using).

sudo apt-get install paman

You can find the input sources under the Sources section and the output devices under the Sinks section of the Devices tab. Make note of the names of the two devices.

2. Unload any previous loopback modules

If you had followed Jon’s previous posts then you will need to unload the modules (and potentially change your PulseAudio configuration so they don’t get loaded again on next restart). This is to stop it from doubling all loopback sound.

3. Create an executable script

Create a script and copy the following command into it:

pacat -r --latency-msec=1 -d [input] | pacat -p --latency-msec=1 -d [output]

where [input] is the name of your input device found in step 1 and [output] is the name of the output device. In my case it would look like:

pacat -r --latency-msec=1 -d alsa_input.pci-0000_05_02.0.analog-stereo | pacat -p --latency-msec=1 -d alsa_output.pci-0000_05_02.0.analog-surround-51

4. Run script

By simply running the script now you should get correct loopback and with much less delay than using the default loopback module. Even better if you set this script to run at startup you won’t have to worry about it ever again.

Shortly after purchasing an xbox360, I wrote a short piece that gave instructions for forwarding your line-in audio through your pc speakers. By using this method and sharing my network connection, I’ve managed to run my xbox as a peripheral to my main computer setup, saving me space and money.

Lately however, the line-in loopback has not been working as expected. At times, it sounds like effects have been applied to the line. In particular, it sounds like somebody has applied a phaser or a delay effect to the input signal.

For the last week or so, I’ve been scratching my head about this issue, trying to figure out what part of my system may have applied effects to my loopback, but not to other audio on the system. Tonight, I was reviewing my original instructions for setting the thing up, and noticed that the module was being loaded on startup after being added to a system config file:

sudo sh -c ' echo "load-module module-loopback" >>  /etc/pulse/default.pa '

On a hunch, I took a look at the end of the file, and found the following lines:

### Make some devices default
#set-default-sink output
#set-default-source input
load-module module-loopback
load-module module-loopback

It looked like the instruction to load the loopback module had ended up in the config file twice! Because of this, the module was being loaded twice on startup.

So what does this have to do with the effects on the line? Well, if you play two copies of the same sound with a half-second gap between them, your ears will be tricked into thinking that you’re hearing one copy of the sound, but that it’s all echoey, as if a delay effect had been applied. If you repeat the experiment but this time decrease the gap between the two sounds even further, say to a few milliseconds, your ears will hear one copy of the sound with a phaser effect applied.

Essentially, when the module loaded twice, it was capturing the mix from the line-in port twice and playing back two separate copies of the audio. Depending on how close together these instances  were, the result sounded normal, phased, or delayed. I fixed the issue by removing one of the lines and then restarting the machine. This time, it started only one copy of the service, and everything sounded fine.

The moral of the story: If you’re loading modules at startup, make sure that you only start one copy of them.

If you have been following my posts on here you’ll know that the hardware I am running this experiment on is relatively new. In fact it’s so new it hasn’t even been shipped to me yet!

Here’s the problem: the large company that I ordered my laptop from seems to be having difficulties getting my order right. Three, count them, 1, 2 and 3, restarts later I finally have an order in production that looks like it might actually be correct. The only problem now is that its new expected delivery date is September 3rd. If it comes down to that and I do miss the start of the experiment does anyone have any suggestions about what I could do for those first couple of days? Let’s hear ‘em!