Recording VoIP calls using pulseaudio and avconv

For ages, I've wanted an option in Skype or Empathy to record my video and voice calls¹. Text is logged constantly because it doesn't cost much in the form of resources, but voice and video are harder.

In lieu of integrated support inside Empathy, and also because I mostly use Skype (for various reasons), the workaround I have is to do an X11 screen grab and encode it to a file. This is not hard at all. A cursory glance at the man page of avconv will tell you how to do it:

avconv -s:v [screen-size] -f x11grab -i "$DISPLAY" output_file.mkv

[screen-size] is in the form of 1366x768 (Width x Height), etc, and you can extend this to record audio by passing the -f pulse -i default flags to avconv²—but that's not quite right, is it? Those flags will only record your own voice! You want to record both your own voice and the voices of the people you're talking to. As far as I know, avconv cannot record from multiple audio sources, and hence we must use Pulseaudio to combine all the voices into a single audio source!

As a side note, I really love Pulseaudio for the very flexible way in which you can manipulate audio streams. I'm baffled by the prevailing sense of dislike that people have towards it! The level of script-level control you get with Pulseaudio is unparallelled compared to any other general-purpose audio server³. One would expect geeks to like such a tool—especially since all the old bugs with it are now fixed.

So, the aim is to take my voice coming in through the microphone, and the voices of everyone else coming out of my speakers, and mix them into one audio stream which can be passed to avconv, and encoded into the video file. In technical terms, the voice coming in from the microphone is exposed as an audio source, and the audio for the speakers is going to an audio sink. Pulseaudio allows applications to listen to the audio going into a sink through a monitor source. So in effect, every sink also has a source attached to it. This will be very useful in just a minute.

The work now boils down to combining two sources together into one single source for avconv. Now, apparently, there's a Pulseaudio module to combine sinks but there isn't any in-built module to combine sources. So we route both the sources to a module-null-sink, and then monitor it! That's it.


pactl load-module module-null-sink sink_name=combined
pactl load-module module-loopback sink=combined source=[voip-source-id]
pactl load-module module-loopback sink=combined source=[mic-source-id]
avconv -s:v [screen-size" -f x11grab -i "$DISPLAY" -f pulse -i combined.monitor output_file.mkv


Here's a script that does this and more (it also does auto setup and cleanup). Run it, and it should Just Work™.

Cheers!

1. It goes without saying that doing so is a breach of the general expectation of privacy, and must be done with the consent of all parties involved. In some countries, not getting consent may even be illegal.
2. If you don't use Pulseaudio, see the man page of avconv for other options, and stop reading now. The cool stuff requires Pulseaudio. :)
3. I don't count JACK as a general-purpose audio system. It's specialized for a unique pro-audio use case.

Android and Disk Encryption

Beginning with Android 3.0 (Honeycomb), Android includes the ability to transparently encrypt your phone's storage using the phone's settings. Internally, this works by using dm-crypt — just like every other Linux distro out there. But what I found intriguing about this was that it only allows you to encrypt your phone if you use either a password or a numeric pin to lock your phone.

This means that the password/pin is shared between the screen lock and dm-crypt. This has a number of consequences which I'll talk about below.

Now, I understand why this is the default behaviour. Most users rarely, if ever, reboot their phones, and so if the phone has a (separate) passphrase for dm-crypt, we'll see users flooding service centres to get their phone "un-bricked" because they forgot they even had a passphrase.

What surprises me is that there's no stock method to set a different passphrase for dm-crypt. Even CyanogenMod doesn't have this feature built-in. The only easy-to-use way I know to do this is by using the Cryptfs Password app (Disclaimer: I haven't actually tried the app itself, so I can make no guarantees about it).

What also surprises me is that Android accepts pin numbers as dm-crypt passphrases, but not lock patterns! This decision makes little sense to me. Pattern locks are almost equivalent to pin numbers because as can be seen below, your pattern lock directly corresponds to a number.

I say almost equivalent because from each node on that grid, you can only access adjacent nodes to create patterns, and this reduces the number pattern space by a bit (and there's no zero). But if this is a problem, then pin numbers shouldn't be allowed either since a numeric passphrase is trivial to crack— as anyone silly enough to use a numeric bicycle lock has found to great distress.

And even if the screen lock is set using a password, the user is extremely unlikely to use anything but a trivial password for securing a screen that they unlock tens of times a day. This again means that the passphrase would be ridiculously easy to brute-force if the attacker has physical access to the phone.

The level of security for a screen lock is just massively different from the level of security suitable for full-disk encryption. It's really good that the groundwork for this feature has been done, but as it stands the feature is mostly pointless.

PS: The phone wallpaper in the screenshot was brought to you by, Pattrn!

GUADEC 2012, A Coruña

This will be my first GUADEC, and I'm looking forward to it. Thanks to my employer Collabora for sponsoring this trip!

I'll be around from 25th evening to 30th morning. Hope to see you all there. :)

Wired, headline click area

Something has always bothered me about the story links on Wired magazine's home page. Today it bothered me enough to write about it.

I don't know if they do this on purpose, or whether it's just an oversight. If it's on purpose, I'd love to know the reason why.

So here's a story; and I hover over the text:

There you go, it lights up and I can click on it… Oops! I moved my mouse by just a few pixels, and:

Ew, I missed! I can't click on it any more.

Fitts' law, my friends, is being violated. Why are they making it harder for me to click on their headlines?

Ars Technica doesn't seem to have this problem. No matter where I hover inside a headline, it still lights up as a link, and I can click to view it:

The difference comes because Ars Technica surrounds the entire span with the hyperlink anchor, whereas Wired only surrounds the text.

I find this somewhat upsetting.

An unintended gem about usability

<UU> Somedays, I think why can't we have computers which just work.
<UU> But then I remember that I am a Computer Scientist.
<UU> So, yeah, I guess I understand why.
<Nirbheek> :D

Quite related to GNOME, really.