Among other features, Hardy comes with PulseAudio, the new sound system which has a lot of features.

As I am playing with Maemo I have installed a scratchbox too. A workmate, Calvaris, wrote about how to install scratchbox in a Linux Amd64.

Now the problem: scratchbox comes with esound to manage the sounds. When I am working within the scratchbox, esound daemon blocks the /dev/dsp device, preventing other applications outside the scratchbox to be able to play. This disturbs me a lot, as I like listening music while working. Of course, we can kill esd daemon to free the dsp device, but in this case I can not play songs inside the scratchbox, which I need to do too.

So, what is the solution? The idea is to use the soundcard to play songs for our Ubuntu applications, while the scratchbox will use a virtual soundcard that will sent the music to another host using networking capabilities of esound. The trick is that the ‘another host’ will be our own host, which will receive the music stream and will play it. Cool, uh?

Lets do it!.

Configuring PulseAudio

The first step is configuring Pulseaudio to be able to receive streams through the network. Therefore, edit /etc/pulse/default.pa and add the following line:

load-module module-esound-protocol-tcp

It is likely that line already exists in the file but commented. In this case, uncomment it.

Now you must restart pulseaudio in order to load the new configuration.

Configuring a Dummy Soundcard

Scratchbox esound daemon requires to have a dsp device even when sending the music through network. So we are going to add a dummy sound card that will be used by the daemon.

Linux kernel provides a driver for a dummy soundcard. To load it, execute as root:

modprobe snd-dummy

A new dsp device, /dev/dsp1, will be created.

Configuring Scratchbox eSound

We must configure esound daemon in scratchbox to use the new dummy soundcard. To do this, enter in the scratchbox and edit /etc/esd.conf file. Search the options line and add at the end:

-d /dev/dsp1

In my case, the esd.conf file contains:

auto_spawn=1
#spawn_options=-promiscuous -nobeeps
spawn_options=-promiscuous -nobeeps -d /dev/dsp1
spawn_wait_ms=500
# default options are used in spawned and non-spawned mode
#default_options=-promiscuous -nobeeps
default_options=-promiscuous -nobeeps -d /dev/dsp1

Thus, scratchbox will use the dummy soundcard, while the real soundcard will remain free for Ubunutu. Of course, being a dummy sound card, don not expect to hear music playing in the scratchbox. To resolve this problem, the last step is send what is playing with esound daemon through the network to our own host to be played through pulseaudio.

Configuring eSound’s Network Transparent Sound

This is the last step. Network sound uses a authentication mechanism. So in order to use network transparency both sides must be authenticated between them. When pulseaudio is launched, an .esd_auth file is created in the home directory. Copying this file to the scratchbox home will allow esd to send music to pulseaudio daemon. After copying the file, restart esound daemon.

Now we can send the sound to the pulseudio daemon. From the scratchbox, execute this:

esdmon | esdcat -s 127.0.0.1 &

esdmon listens all data sent to esound daemon, sending it also to the standard output. On the other hand, esdcat reads all data from the standard input and sends it (in this case) to the localhost. As you can notice, working together means that all sound sent to the dummy sound card is also sent through localhost to the pulseaudio daemon, which in turn sends it to the real soundcard.

Now, you can play songs inside the scratchbox and you will hear them! Moreover, you can be playing at the same time music in the scratchbox and in the host, due to multiplexing capabilities of pulseaudio. So both systems, Ubuntu and scratchbox, will sing duet.

One of those functions that is very useful is narrow-to-defun (C-x n d): it hides all source code except the current function. Then, you can do all kind of changes that will affect only the shown code. If you try it with a C example, you will notice all code except the function you are positioned is hidden. Unfortunately, as you can check, the function definition is not part of the defun, so it is also hidden. Besides being upset, as you can not see the definition, there are other problems, like Emacs indenting wrong.

But with Emacs22, this has changed, so now a defun includes both the code of a function and its definition. If you try again the previous example in Emacs22, you will notice that now the function is shown fine, and it even indents fine.

The problem is that some Emacs packages are not aware of this change. One of that package is gtk-doc: it creates a skeleton of the Gtk function you are writting. Unfortunately, this package, which works fine until Emacs21, does not work fine in Emacs22, because of the change of defun.

The fix is very easy, and I attach the package already fixed. You need to load Emacs22, and compile it (gtk-doc.el) with compile it with byte-compile-file funtion, which creates a gtk-doc.elc, and then replace the current file with the newer. If you want to have a look at the change done, I attach also a patch with the fix.

So, here is my conclusions. Notice that I’m roughly speaking. Like The Three Musketeers or Three Little Pigs, WebKit is composed by three high level modules: JavaScriptCore, WebCore and WebKit (latter names the global project).

• JavaScriptCore, as its name suggests, is the interpreter of JavaScript.
• WebCore is the core of the project. Implements the render engine itself: analyzes the web pages, generates a DOM tree, a render tree and finally renders it with a backend. There are as many backends as ports. So WebKit/Gdk, the port of WebKit for the best platform uses widgets Gtk/Gdk and Cairo to draw the elements. Though in the figure the backend is separated from WebCore, actually the backend is part of WebCore.
• WebKit is a façade of WebCore. It hides and adapts WebCore to the current platform. In WebKit/Gtk, shows WebCore as Gtk objects, with their signals and API similar to other Gtk objects.

I hope this information be helpful to any one.

One of the most used applications to find buffer overflows is Valgrind. It is very sophisticated, and is able to find other type of problems. The drawback is that it only runs on x86, AMD, PPC32 and PPC64.

When I was studying, I discovered Electric Fence, a library that detect illegal accesses to memory. Roughly speaking, it changes the malloc function, so when a buffer is allocated, it adds around it a “red zone”: if you touch that zone, the program aborts with a segmentation fault. What is the advantage? It always crashes in the moment you access an invalid position of memory, not 100 or 300 lines far away. So you can use a debugger and see in which line is crashing: surely, in that line there is an illegal access to memory.

How to use it? More simply, impossible. You only need to link your program with the library (-lefence). That’s all! A banner is showed when the program is executed. Even you may use the Electric Fence with an already compiled program if you preload first the library (exporting the LD_PRELOAD environment variable to libefence.so.0.0).

The drawback with Electric Fence is that it makes the program more more slow. So use it only when developing, and disable it in the final release.

And remember: Electric Fence is in almost all GNU/Linux distributions. Happy bug hunting!