DEMAND: Diverse Environments Multichannel Acoustic Noise Database

It's official: our database of recordings with the microphone array described in a previous post is now active and can be found at http://www.irisa.fr/metiss/DEMAND/. Licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License, this is a large chunk of data - so much, we are only putting it on the website in one format, a zip file of 16 mono wav files for each environment.  My preferred format would have been to post it as 16-channel wav files (easier to work with in MATLAB, provided you have loads and loads of RAM) but that decision had to be made.

The original design called for 18 recordings, but one of those was too challenging to do proper around Rennes, and two were unsatisfactory after recording.  So, those will be left for v2.0.  Still, this is a far more diverse set that most other databases I know of - and with more channels.

So if you're into multichannel signal processing... have at it!

Wireless Serial on a Raspberry Pi

I don't have my Raspberry Pi yet.  RS has informed me of a delay - I guess the good news is I should be getting a Rev. 2 board.  In the mean time, a colleague of mine got his a while ago, but due to lack of time is letting me play with it.  I don't have time either, but I'm not letting me stop that!

So the first thing I did, not wanting to mess around with swapping monitors and keyboards etc..., was to hook up the Rπ to a bluetooth serial adapter I got off DX. ($8.60!, see also here)  It was trivial to hook up to the Rπ, but make sure to hook Vcc up to 3.3V! Otherwise, the TX line will probably output 5V TTL levels that could damage the Rπ input pin.  So, the hookup is, (adapter pin:Rπ pin) VCC: P1-01, GND: P1-06, TXD: P1-10, RXD: P1-08.

Software wise, there is not much to do either.  I left the adapter at 9600 baud; at some point I will send it the magic AT incantation to change that, but at the moment it was simple to just change numbers on the Rπ, all of which can be done on the SD card using another computer running Linux (in other words, the Rπ never needs to be hooked up to a monitor/keyboard).  In the boot partition, change the baudrates for ttyAMA0 to 9600, and in the actual real linux root partition, change the appropriate inittab line.  (details will follow - I don't have the board in front of me)

The biggest problem is the power.  As the Rπ (rev 1) does not have a halt or reset line, the bluetooth adapter will get power at the same time as the Rπ, so you cannot connect to it before the Rπ boots - on the Rev 2 board I think I could hold it in reset state until I've connected the bluetooth so I can monitor all bootup messages.  The other solution would be to give BT adapter its own 3.3V supply but that could also be dangerous for the serial input line of the Rπ.

LASERS! on (virtual) paper

Yay, another journal article! Ok, ok, I'm 8th author (out of 13 - quite the horde) but it's still good (besides, I wasn't able to contribute much after leaving Montreal). Kudos to Philip and his gang.  The paper was published in Analyst, a journal of the Royal Society of Chemistry; the article itself ("Demonstration of a plasmonic thermocycler for the amplification of human androgen receptor DNA") can be found here.  For reference this was the project I was playing with when I wrote this post.

In related news, the ICASSP 2012 paper (mentioned in this post) is finally in IEEE Xplore.  That took a while.  Now back to research to write a paper on my current research!

Panasonic HHC Schematics by Tony Duell

(TL;DR version: the scans are here)

Some years ago, I picked up a Panasonic HHC, having had an interest in the small hand-held BASIC computers for a while.  As it turns out, the HHC does not use basic at all, and is by default not really "open" in any way - there was a BASIC ROM available, but generally the thing was used as a specialized calculator with custom ROMs.  Still, It's a cute little machine with the interesting feature of using a 6502 inside, and it came with a printer that uses regular paper, and even the internal batteries still work.

Recently, there was a discussion about it on the Classiccmp mailing list, and Tony Duell - known for his classic computer electronics acumen if not his take-no-prisoners approach to typing emails - mentioned that he had traced out the circuits of this little machine.  This got me (and several others) interested, and he offered to make these available to the general public if someone would scan them and place them somewhere on the web.  The physical pieces of paper from Tony were scanned by Dave Colver, who in turn sent me the images.  I did a bit of cleaning up (nothing more than adjusting levels to remove some JPG compression artifacts) and collated them into a PDF document and you can download them from here: Panasonic HHC RL-H1400 Schematics.

Unfortunately, my HHC is at this moment a couple of thousand kilometers away, in a box at a friend's house in Pointe-Claire, Canada.  However, once I live in a place where I have a workshop again, I will mess around with it, for sure.  Dumping the ROMs would be a good start!

Real life interference again, of the best kind

A short time ago, life has become quite overwhelming, but in a good way.   To announce the reason, I sent a little bit of creative writing to my friends; I'll post it here with the personally identifying information masked out.

CHILD PROCESS (1)        THIEMANN FAMILY INFORMATION        CHILD PROCESS (1)

SUMMARY
     A child process with PID "------ ------ Thiemann" has been successfully
     spawned.  While the process is not yet ready for completely standalone 
     deployment, it operates within all expected parameters.
     
DESCRIPTION
     On --- -- Aug 2012 --:-- CEST, a child process was successfully spawned
     from two parent processes.  The new process was given a PID of "------
     ------ Thiemann".  All parameters are within design specifications, as
     are the parameters of the parent processes.  Note that the new process
     is not functioning as a completely independent unit yet, but relies on
     I/O processing by the parent processes; in particular, the flushed 
     output functionality is not yet present, and instead uses buffered
     output where the buffers are emptied by the parent processes.  Input
     is taken exclusively from one of the parent processes.  Furthermore,
     the self-diagnosis functionality is currently limited to a one-bit sonic
     indicator; if this indicator is activated, it is left to the parent 
     processes to determine if I/O needs to be serviced or if the current
     operating environment is incompatible.
     
     When not performing I/O, the new process spends a considerable amount 
     of time in the sleep state.  A visualization of the process is appended
     to the report, showing the interaction of the new process with its
     parent processes.
     
BUGS
     As of yet, no bugs have been found in the system that merit intervention
     by either the parent processes or the operating system.  However, it is
     expected as the process interacts with the greater system environment,
     some abnormal processing states may occur, but it is expected that the
     self-repair functions will be fully functional by that time.
     

I know the "thing to do" these days is to have a facebook page, twitter account, email address, etc. for a new kid set up.  Well, this kid's information will be off the net for as long as possible, until he is capable of understanding and deciding for himself.  But watch out world once he gets his hands on a soldering iron and/or a compiler!

Simple multithreading using clone()

For a bit of hacking I want to do, I need to implement concurrency between two processes sharing the same memory.  So I looked into how to do it (this is all under Linux). My first stab was to look at the old SYSV shared memory interface - but that was kind of ugly, then I looked at pthreads and thought the same. Isn't there a simple way to do fork() without splitting the memory?

Turns out, Linux does have such a mechanism, in the clone() function call. However, there are some pitfalls that one needs to be aware of. Let's see the code first, though.

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <linux/sched.h>

Pretty standard stuff, but note the last one: it's important to pick that rather than <sched.h> (as the man page claims), since otherwise you don't have the necessary constants defined!
Next, we need some memory in global space:

#define STACKSIZE 256
int globalint;
char stack[STACKSIZE];

The lone int is the only memory that I'm using to communicate between the threads for now. The stack however, is only used by the child thread/process. It is visible to the parent, but it's not easy (or reliable) to use it to communicate with the child. Now let's define the code for the child process.

int secondp()
{
  int i;

  for (i=0; i<1000; i++) {
    globalint = i;
    usleep(60000);
  }
  return 0;
}

Simple enough: every 60 ms, set the global variable to the value of of the local one being incremented. Note I am NOT "incrementing" the global, since that would be a read-write operation, which gets computer science people all excited in multiprogramming situations! (Or it did, 70 or so years ago.)
Now let's have the main program.

int main()
{
  int i, j, sppid;

  for (i=0; i<STACKSIZE; i++) stack[i] = 0x55;

I initialize the stack so I can observe what happened to it during execution, filling it with a simple 010101... pattern. Next, the interesting bit.

  sppid = clone( secondp, &stack[STACKSIZE], CLONE_VM, NULL );
  if (sppid==-1) {
    printf("clone error.\n");
    exit(1);
  }
  printf("clone pid 0x%08x\n", sppid );

The first line creates the child process, given the pointer to the function as the first argument. The second argument is what that process gets as a stack - but note that the pointer points to the TOP of the stack! This is x86 specific and MAY (or may not) be different on other architectures (ARM? amd64?).
The third argument, the options, is what creates the magic to make this shared memory scheme work. Without it, clone() behaves more like fork(), giving the child a copy (-on-write) of the parent memory space, which is exactly what I don't want. Other options allow you to copy or share specific elements, like the file I/O table etc. Read the documentation. Lastly, the following arguments are passed to the child function - useful in many instances, but not used here.
I finish up the program with code that actually demonstrates that things are happening as expected:

  for (i=0; i<10; i++) {
    printf("%d\n", globalint);
    fflush(NULL);
    usleep(1000000);
  }

  for (i=0; i<16; i++) {
    printf( "%04x :", i<<4 );
    for (j=0; j<16; j++) {
      printf( " %02x", stack[j+(i<<4)]&(0xff) );
    }
    printf( "\n" );
  }

  return 0;
}

So, for 10 seconds, the value of the global integer is printed; after that, I dump the stack in a hexdump fashion. This is what I get on my Ubuntu Netbook:

clone pid 0x000005e3
0
16
33
49
66
83
99
116
132
149
0000 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0010 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0020 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0030 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0040 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0050 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0060 : 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55
0070 : 55 55 55 55 55 55 55 55 55 55 55 55 48 f2 0e 08
0080 : e0 8e 04 08 00 00 00 00 6f 58 08 08 cd 84 05 08
0090 : 08 f2 0e 08 00 00 00 00 55 55 55 55 55 55 55 55
00a0 : 55 55 55 55 55 55 55 55 00 00 00 00 00 87 93 03
00b0 : 55 55 55 55 55 55 55 55 55 55 55 55 03 8f 04 08
00c0 : 60 ea 00 00 55 55 55 55 55 55 55 55 55 55 55 55
00d0 : 55 55 55 55 55 55 55 55 55 55 55 55 a6 00 00 00
00e0 : 55 55 55 55 00 01 00 00 00 00 00 00 2e 96 05 08
00f0 : 00 00 00 00 55 55 55 55 55 55 55 55 55 55 55 55

Clearly, the global int is modified by the child process while being read by the parent. The stack display is interesting, showing clearly how it's being filled towards lower memory. A x86 expert could probably explain clearly what is there and why the stack is not written to contiguously (presumably, some of it is allocated byt never written to).
Thus, the three main things to keep in mind when using clone() are:

• Make sure you use the right sched.h file.  (You'll notice this at compile time)
• Choose the proper options to clone()
• Make sure you know which way the stack grows, and how big it'll get!  If you get this wrong, it'll clobber the parent variables - if you use malloc() instead, you'll get a memory fault (which is preferrable since it's slightly easier to diagnose).

Enjoy!

Journée Science et Musique 2012

A few months ago, I got roped into helping to get the "Journée Science et Musique 2012" event off the ground.  Mostly, my contribution to date has been to be a part of the team wrangling an ugly mess of HTML, PHP, and CSS into shape.  Well, as of yesterday that abomination is live and open to the public.  As we get closer to the date, I'll probably get involved into other parts of the event as well - in fact I have two demos that I'm working on that we might show off at the event.

I'm looking forward to it, it should be a lot of fun.