From the Wikipedia page for Ashen light:
“Ashen light is a subtle glow that is seen from the night side of the planet Venus.”

“Before the development of more powerful telescopes, early astronomer Franz von Gruithuisen [March 19, 1774 � June 21, 1852] believed that Ashen light was from the fires from celebration of a new Venusian emperor, and later believed that it was the inhabitants burning vegetation to make room for farmland.”

Nice theories, don’t you think? It was likely the best speculation of its time, but just consider how human culture centric those thoughts really were.

1. “fires from celebration of a new Venusian emperor” = Venus has an emperor – implying a hierarchical society – celebrations are conducted on a primitive fashion through the lighting of massive planet-wide fires.
(more…)

I don’t really use Skype at home that often. Today I did, and I ran into a problem which I remembered having a long time ago: the voice call audio from me to others sounds lower in pitch, like Darth Vader, or one of those “voice altered to protect the identity” things on TV.

This time, I was arsed enough to fix the Skype issue.

The cause is quite simple: Skype’s SILK voice codec wants to record audio in 24 kHz. However, my HD Audio using Realtek ALC883 chip does not support that sampling rate. Instead, it defaults to 44.1 kHz. The result sounds interesting, but useless for talking over Skype.

So how to fix this? Theory of operation: whatever sampling rate Skype asks you for, just say yes, record in whatever the hardware supports, then rate convert to the sampling rate asked by Skype. This will solve the problem.

To do this in practise, using ALSA, is as follows. First, quit Skype. Don’t just log out, quit the whole thing.

Then, let’s add a software SRC into the proper point in the voice audio uplink path (nerdy!) by adding the following to your ~/.asoundrc:

pcm.skype {                                                                                  
    type plug                                                                                
    slave {                                                                                  
        # normal ALC883                                                                      
        pcm "hw:0,0"                                                                         
                                                                                             
        # skype wants 24 kHz recording input,                                                
        # but ALC883 doesn't support that.                                                   
        # do a rate conversion on the fly.                                                   
        rate 48000                                                                           
    }                                                                                        
}

Note: change the pcm “hw:0,0″ line to whatever is your device – this one uses the default.

To test your new .asoundrc, you can use the command arecord -f S16_LE -c 2 -r 24000 -D skype -d 20 test.wav

If the recording gave no errors, play it back with aplay test.wav. If it sounds OK, you’re good to go.

Next, start Skype. Then go to Options, and set the recording audio device to be “(plug) skype”.

It worked for me, testing using Skype’s echo123 service yields crystal clear audio!

My secret evil scientist projects needed a simple and straightforward way to implement (Mealy) FSAs in Python. I didn’t find an appropriate one, so I made one from scratch which turned out to be a fun learning experience.

You can download it here: statemachine.zip

It’s quite simple to use, please see the runner.py and runner2.py scripts for a demonstration.

The major “selling point” here is that it’s light-weight, and each state defines the transitions; there is no global transition-table. I find it simpler to implement state machines in such OO way. When the FSA is sketched (on paper! Yep I’m old skool), I find it easier to map the transitions correctly by just focusing on one state at a time, seeing what conditions transition to it, what outputs/actions does it make (I don’t really use Moore) and where does it transition to, and so on.

If you need a quick-and-dirty agile and simple solution, do have a look.

There are downsides: each State-derived state-specialization has to be unique (currently it’s not possible to “share” a state class instance by variating an instance to become a different state based on parameters given during construction time, this is due to the way the FSA builds a list of the states; it’s easy to change though), and you have to pass data either in some data container class, or use global variables.

How to use it

Please see runner.py and runner2.py.

In a nutshell: Inherit your specialized states from State. Implement enter, work or exit methods, you need at least the work-method. State transition is done in the work-method: return states[SomeClass] to transition to SomeClass, or return STATE_MACHINE_EXIT when the FSA is done.

The initialization is done by giving the FSA class a list of your state instances in the constructor. The initializing state must be the first one in the list. Then you can refer to these state instances inside the states with states[SomeStateClassOfYours].

Run the FSA by calling work() on it. It returns a generator, so that you can run the FSA in steps, if needed.