Text to speech on linux

My previous searching had led me to believe that the first stop for text to speech on linux is a program called “festival”. However after much more searching it seems that flite is the successor to festival.

Example Usage:

flite -voice kal16 <<< “Hello world”
flite -lv # To see the available voices

Tagged with: ,
Posted in Uncategorized


I had a problem with one of my programs going abnormally slow.  Being a linux developer, one of the steps I took to diagnosing the problem was to strace the executable. Interestingly it showed me that I was accessing /usr/share/zoneinfo/GMT a ridiculous quantity of times.  What I needed then was a stack trace at the time /usr/share/zoneinfo/GMT was opened.  strace doesn’t provide that information.

A bit of search engine work reveals


but that seemed a bit like too much work.

A bit more learning about gdb taught me that you can break on syscalls using

catch syscall

Now this might have worked but the file I was opening a lot was well after the program startup, so I decided to keep looking for a better solution.  That’s when I discovered


strace-plus is a version of strace with a call stack print out at every syscall.  Exactly what I wanted. There are two points to note about that webpage.  First is that the make produces an executable called strace not strace+; so you’ll need to

cp strace strace+

if you want to stay sane.  Secondly in step 3 where they say

./strace+ -o hello.out ./hello

you actually need to use

./strace+ -k -o hello.out ./hello

Note the -k which gets the actual stack trace.

Posted in Uncategorized

Linux Swappiness

I finally got sick of linux (Ubuntu and Centos to be more precise) swapping all the time when I have 8GB and 16GB of memory in the two machines I use all the time.  So I decided that it was time I learnt about how to tune the swappiness.  Turns out that it is particularly simple.

Swappiness is a number between 0 and 100.  0 means swap only to prevent an out of memory condition, 100 means go nuts and swap aggressively.  On both of my machines it was set to 60.

To see what value your system currently has

  • cat /proc/sys/vm/swappiness

To temporarily set the swappiness to something sane, say 10,

  • sudo sysctl -w vm.swappiness=10

To make this value persist across reboots, edit /etc/sysctl.conf as root and insert

  •  vm.swappiness=10


Tagged with: ,
Posted in Uncategorized

Theoretical maximum data rate possible for LiFi implemented with webcams


If you do a quick search you can quickly find more than two million articles about LiFi.  Recent articles I’ve seen have talked about obtaining data transfer rates of GB/s. What I became interested in was whether I could transmit using some sort of cheap light source and then receive using a cheap webcam.  The idea is to simply flash the light and have the webcam detect the flash. So in principle we are treating the webcam as a one pixel device and not taking into account the fact that a webcam can provide spatial awareness.

Generous Hardware Specifications

Let’s assume some rather generous specifications. Say the webcam can refresh at 30 frames per second and presents 256 levels in each of the YUV channels. This means that the number of unique levels the camera can detect are 256 * 256 * 256 =  16777216 (i.e., 24 bits). I’ll assume that my light source can match or exceed these specifications.

Hartley’s Law

It turns out that in 1928 Hartley cracked the problem of determining the maximum data rate (R) that you can send a information at given the frequency (B) at which you can send “symbols” and the number of separate resolvable “symbols” you can receive (M)

R\leq 2B\log_2(M)

Plugging the above, overly generous, numbers into Hartley’s Law we find that the maximum rate we could send is a depressingly low 1440 bits per second.  

Going faster than 1440 bps

So using the above equipment in the way I specified, 1.4kbps is the limit. So to go faster we need to change the assumptions. One way would be to get a receiver that can go much faster than 30 Hz, which means not a webcam.  Another way to go faster is to make use of the spatial ability of the webcam.  Perhaps some sort of QR Code movie?

Tagged with: ,
Posted in Uncategorized

When (as in temporally) does the vtable get set up?


At least for g++, as part of each constructor call. As a derived class object is instantiated the vtable pointer will be updated at each constructor called.

The Zero class

One of the common jobs you have to do in coding is to initialise memory  to sane defaults.  Sometimes the sane default is zero.  Recently a colleague (Brendan Babb) wrote some code to make setting member variables to zero a trivial task.  It went something like

struct Zero
    Zero() { std::memset(this, 0, sizeof(T)); }

struct LotsOfData : public Zero
    int ii;
    char cc;
    long ll;

My first thoughts were cool!  My second thoughts were, uh oh, this is going to cause havoc in any object that has a vtable.  To be concrete, I was predicting that the virtual function call in the following code would fail to work properly.

struct Base
    char cc;

    Base() : cc('B'){}
    virtual ~Base() {};
    virtual const char value() const { return cc; }
struct Derived : public Zero, public Base
    long ll;

    Derived() : ll(0) { cc = 'D'; }
    virtual const char value() const { return 'E'; }

int main( int argc, char* argv[] )
    Base bb;
    Derived dd;

    std::cout << "size of char = " << sizeof(char) << "\n";
    std::cout << "size of long = " << sizeof(long) << "\n";
    std::cout << "Base=" << bb.value() << " sizeof(Base)=" << sizeof(Base) << "\n";
    std::cout << "Derived=" << dd.value() << " sizeof(Derived)=" << sizeof(Derived) << "\n";

    Base* pbase = ⅆ
    std::cout << "Ptr to Base=" << pbase->value() << " and " << pbase->cc << "\n";

Take that code, and compile it with gcc 4.6 or clang  3.0 (on linux) and you will find that the code actually works as you would expect and not fail as I expected.

Quick introduction to vtables and vtable pointers

I am not a compiler writer so take this section with a grain of salt.  I’ve picked up this knowledge over years by talking to more senior programmers, reading articles, and watching memory in a debugger. Also when you read text books on C++ you don’t usually get taught about vtables because strictly speaking they are not part of the language. vtables are a construct that compiler writers invented to help them implement the language.

So what are they? vtables are arrays of function pointers.  But let’s take a step back.  When a simple class like LotsOfData is instantiated as an object, all the compiler needs to do is set aside some memory for the data. Typically the object will take more space than the sum of its part as the compiler often puts in some padding space so that member variables start on word boundaries (which allows most cpus to access the data faster). Notice that there is no mention of vtables in this case.

vtables are only necessary for a class that has virtual functions.   In the code above, there is a pointer called pbase.  pbase can validly point to an object of type Base or an object of type Derived. When code like pbase->value() is called, the decision of whether Base::value or Derived::value is called must be determined at runtime.  As with all problems in computer science, compiler writers solve this problem by using a level of indirection. Specifically, they create one array with pointers to the functions for the Base class and another array with the pointers to the functions for the Derived class. These arrays are the vtables.  Then in each (and every) object of type Base and Derived, they insert a pointer to the appropriate vtable. So at runtime when pbase->value() is called the vtable pointer that is in the object is dereferenced to determine which vtable to look up which then in turn contains the pointer to the correct value function.  So finally after multiple indirections we have the correct value function to call. As an aside, the reason a pointer to the vtable, rather than simply inserting the whole vtable into every object, is to save memory.

Another point to note is that when sizeof(Derived) is called, the returned size is the size in bytes necessary for new (or malloc) to set aside to contain an object of type Derived. That is, the size returned includes enough space for the vtable pointer and padding.

Why did I think it would fail?

What I was worried about was that memset in the Zero constructor would overwrite the vtable pointer in the Derived object. If that vtable pointer has been overwritten to zero (i.e., the null pointer) then the implicit vtable pointer dereference that occurs in pbase->value() would cause a segfault.

So the question comes down to what is the temporal ordering of the creation of an object. Two weeks ago I naively thought that because the new call knows exactly the type of the object being created so it would insert the correct vtable pointer as the first step after memory allocation. The next step would be constructors called with the Zero constructor being called first and thus the Zero constructor would wipe out the vtable pointer.

What actually happens?

Now since the code doesn’t fail like I predicted, what is going on? For the investigation I used gcc 4.6 and clang 3.0 running on Ubuntu 12.04.  If you use a different compiler, and/or a different platform, you could end up with different results. I compiled up the code (remember the -g compiler flag) and then used kdbg to inspect the memory of the bb and dd variables in the above code.

What I found was that the vtable pointer updated as the construction process proceeded. As a C++ programmer you would know that as part of the construction process the base class is constructed first and then builds up to the most derived class. I was able to observe that both gcc and clang set the vtable pointer as one of the first actions of calling a constructor.  To be concrete, constructing dd calls Zero::Zero() and Base::Base() before calling Derived::Derived().  Zero does its job and wipes the memory (including the space for the vtable pointer) to zero. Next, the vtable pointer in dd is set to point to the Base vtable as the first action of the Base::Base() . Then the first action when Derived::Derived() is called is to update the vtable pointer to the Derived vtable.

Why the multiple updating of the vtable pointer when the final value is known?

As far as I can guess, the answer is to provide a measure of safety.  Imagine a compiler that just directly set the vtable pointer to the final value as the first part of constructing an object. In that case, if a base class called a virtual function as part of the constructor, the virtual call would resolve to the derived class function.  However the derived class data has not been set up yet and if the derived function relied on this unset data then bad joojoo would happen.


On one hand, the zero class is very cool. On the other hand, it will might wipe out the vtable. But on the gripping hand, most likely all is well.

Tagged with: ,
Posted in Uncategorized

Why doesn’t debugger stop at breakpoint?


Remember to give the -g option to the compiler.

The problem

Tonight I was trying to make a toy example program and wanted to examine the memory of some structures.  I do this all the time at work, but we usually use Eclipse. Now for my toy program I wrote the 50 lines of C++ up in geany and noticed that if you hit F9 it will build such a simple program for you.  Bonus!  Ran the program and the output is as expected.  [By the way, at work and home I use linux.  Centos at work, Ubuntu at home].  So lets fire up a debugger and have a look at that memory.

Attracted to shiny things

Many moons ago when I started my first stint as a professional code monkey, Visual Studio 6 was the tool of choice . Now while I used to whinge about its many failings, I was deeply attracted to the integrated debugger.  That debugger really changed the way I chased down problems. Fast forward through time to tonight and I wanted to fire up a debugger.  So do I just use gdb?  Or do I fire up a graphical debugger.  I’m still partial to the shiny debugger so up I fire ddd.  ddd ran my code (as in output appeared) but for the life of me I could not get it to show me the source.  OK, no worries, it’s been a decade since I last used ddd, so let’s just jump ship and use kdbg.  Load up the executable and source, set some breakpoint, hit go and the program merrily wizzes past them like they didn’t exist!


Reluctantly I read the manual.  Luckily the manual is actually very short!  Unluckily the manual gave me no clue as to what was going wrong.  Next up, search the web. Thankyou to http://pascalg.wordpress.com/2007/03/10/debugging-cc-with-kdbg-kdevelop/ for the excellent comment

<quote>First you need to compile your c/c++ source with “-g”(this is very important). E.g gcc test.c -g </quote>

And there was my issue.  The default geany build command doesn’t specify -g in the options. Just in case you are wondering, the -g tells gcc to produce debugging information. kdbg now stops correctly and I bet ddd will too when I go back and try.

Tagged with: , ,
Posted in Uncategorized

Compiling raspistill

Raspberry Flavoured Goodness

I am working on a problem where I need to capture images with a camera and put them on a large screen.  The raspberry pi with its optional camera board, and a large screen TV are the perfect elements to solve this problem.  The program raspistill will take an image and put it on the screen for you which solves most of my problem.  Thankfully the raspistill is open source software and so my attack plan was to examine that code then modify it to my needs.

Initial compile

Getting your hands on the source code for raspistill is easy

git clone https://github.com/raspberrypi/userland.git

Then I mostly used the instructions from http://thinkrpi.wordpress.com/2013/05/22/opencvpi-cam-step-2-compilation/

  • cd userland
  • sed -i ‘s/if (DEFINED CMAKE_TOOLCHAIN_FILE)/if (NOT DEFINED CMAKE_TOOLCHAIN_FILE)/g’ makefiles/cmake/arm-linux.cmake
  • cmake -DCMAKE_BUILD_TYPE=Release
  • make

<Patience> <More patience> All compiles! If only most software was this well behaved.

Speed Bumps

Since my final goal is to make an executable like raspistillyuv, why not use raspistillyuv as a proxy to let me sort out the build environment. Using find for a while located the source code at userland/host_applications/linux/apps/raspicam/RaspiStillYUV.c.  So I created a new directory /home/pi/raspicam  and copied RaspiStillYUV.c to it. A bit of include chasing also showed that I needed to copy

RaspiCamControl.c RaspiCLI.h RaspiPreview.h RaspiCamControl.h RaspiCLI.c RaspiPreview.c

The simple plan was to compile and link the c files.  On the Raspberry Pi its well known that you have to include some extra paths in order to make progress. So my first guess at a compile command was[1]

g++ -I . -std=gnu++0x -isystem /opt/vc/include/ -isystem /opt/vc/include/interface/vcos/pthreads/ -isystem /opt/vc/include/interface/vmcs_host/linux/ RaspiStillYUV.c

and we promptly hit the following error

RaspiStillYUV.c:62:33: fatal error: interface/mmal/mmal.h: No such file or directory

Hunt for the missing headers

Now all the raspberry pi specific code is usually found under /opt/vc/include.  Searching under here shows that there is no mmal.h installed. I did find /opt/vc/lib/libmmal.so.  So how did this get onto the system? dpkg can do the reverse lookup for us

$ dpkg -S /opt/vc/lib/libmmal.so
libraspberrypi0: /opt/vc/lib/libmmal.so

This would normally mean that the associated headers would be included in libraspberrypi0-dev which doesn’t exist.  libraspberrypi-dev does exist but

$ dpkg -L libraspberrypi-dev |grep mmal

gives nothing. libraspberrypi-dev (1.20140618-1) now does contain these headers. Be careful of what you trust in the original blog entry (this update was written on 20140627) Also

$ apt-file search mmal.h

gives nothing.

However, since the userland repository compiled up the camera binaries it must contain all the mmal code.  And a find turns up



It would appear that the mmal headers would naturally go under the /opt/vc/include/interface directory. A tempting solution is to just copy the headers into the directory and declare the job done, however having been down that path I know it is the darkside (been free of the darkside since 2002) and always ends in tears/reinstall of OS.   The correct solution is to make a package.

The fastest way I could think of to create a deb package is

$mkdir mmal-dev-20130909 && cd mmal-dev-20130909
$cp -r ~/userland/interface/mmal .
$cat >Makefile <<EOF
	cp -r mmal /opt/vc/include/interface/

	rm -rf /opt/vc/include/interface/mmal
$sudo checkinstall

Back to the problem of compiling RaspiStillYUV.c

Rather than writing Makefiles, I use a program called cake that writes the Makefile and then calls make. The CFLAGS that cake uses on the raspberry pi are

-I . -fPIC -g -Wall -march=armv6 -mfpu=vfp -mfloat-abi=hard -isystem /opt/vc/include/ -isystem /opt/vc/include/interface/vcos/pthreads/ -isystem /opt/vc/include/interface/vmcs_host/linux/

which leads to the link error

undefined reference to `mmal_component_create'

Which means that we also need to specify the following link flags

-Wall -Werror -march=armv6 -mfpu=vfp -mfloat-abi=hard -L /opt/vc/lib -lbcm_host -lmmal

And then all is well.


1. Ha! On a proof read I discovered that I’ve outed myself as a C++ programmer not a C programmer. 🙂 Back to Post

Tagged with: , ,
Posted in Uncategorized