The joys of Xorg and nVidia drivers

I just upgraded Xorg on my debian machine and most GTK 2 widgets lost their borders. How annoying. Turns out the latest xserver-xorg-video-nvidia driver isn’t compatible with the latest Xorg ABI but; this driver doesn’t tell you, a more recent version will complain:

================ WARNING WARNING WARNING WARNING ================
This server has a video driver ABI version of 11.0 that this
driver does not officially support. Please check for driver updates or downgrade to an X
server with a supported driver ABI.
(WW) NVIDIA: The driver will continue to load, but may behave strangely.
(WW) NVIDIA: This driver was compiled against the X.Org server SDK from git commit b6c7b9b2f39e970cedb6bc1e073f901e28cb0fa3 and may not be compatible with the final version of this SDK.
(WW) NVIDIA: This server has an unsupported input driver ABI version (have 13.0, need < 13.0). The driver will continue to load, but may behave strangely.

The solution was to carefully downgrade xserver-xorg-core to 2:1.10.4-1 (that required downgrading xserver-xorg-input-evdev xserver-xorg-input-wacom too). Back with Xorg ABI 10 and everything works ! I now have border on my widgets !

sudo apt-get install xserver-xorg-core=2:1.10.4-1 xserver-xorg-input-evdev=1:2.6.0-2+b1 xserver-xorg-input-wacom=0.10.10+20110203-1)

The Singleton Pattern Revisited

Need to test a singleton ?

Suppose you have singleton class A:

class A {
public static A getInstance() {...}

private A() { ... }
public int doStuff() { ... }

How can you test it if you can’t use your mocks ? Simple put it in a package and make ASingleton that creates A using a constructor package default ! Since your tests run in the same package you will be able to extend it and use your mocks while still having a semi-private constructor.

class A {
A() { ... }
public int doStuff() { ... }

class ASingleton {
private ASingleton() {}
public static A getInstance() { ... }

Responsive Design: don't block the workflow

I’m currently designing the interface and testing the workflow for the whole iPad/iPhone application I’m making and everything is well when everything works. However, in the current setup that I have the Insteon nodes don’t get messages from time to time; with power line signaling there is always something that can go wrong and this is why I prefer dedicated wiring but I had no choice. What happens when a message is lost is quite irritating; the GUI just sits there util the server hits a timeout. This really breaks the flow of the user. So let’s look at why this happens.
Continue reading

QT Gui

The home automation needed a GUI to control and show the status. That’s why I started working on a small QT application in C++ that will be running on an embedded ARM with a 7 inch touch screen. The project is available on Github. For now I have a video demoing the latest version.

The music back end is MPD. Communication with the home automation (which I’m also doing, in Java) is via Stomp. This is how the weather is pushed.

Stay tuned for more and follow me on Twitter !

4 Way Crossover for the MonsterSpeakers

Today marked another milestone; the cross-over for my 4 way active speaker is done. The input is a XLR followed by a very common instrumentation amplifier before entering the real crossover it is buffered and split to the signal detection circuitry. This last bit of circuitry is not mine; I originally designed one with a 2.5v voltage reference and another one with a comparator with build-in reference like a LT6703HV however, Rod Elliott‘s idea on Project 38 was very nice; a simple dual op-amp and voltage divider.

As always, comments are welcomed. Schema and Eagle Project files are provided. (Full view for links)

Monster Speakers Sketchup

Monster Speakers Sketch up

Monster Speakers Sketch up

Tonight I spent some time in Google Sketchup to sketch up my speakers. This is my ever lasting project and every bit helps to keep myself motivated ! I’m uncertain about the colors and the finish to use as it will all be MDF but the current render gives a good idea.

The project is a 4 way active system; with 2 subs, lower voice, upper voice and tweeter. I have completed an analog crossover but I’m tempted to replace it with a variant of the DSP board I published earlier. The system will feature the ability to turn on when “detecting audio” or with 12v triggers. An output trigger (also 12v) will be present and independent of the input trigger; it will turn on with the “speaker” so I can power/trigger other equipment.

The two subs will likely be a Class-D amplifier based on a TAS5630 while the voices will be based on a LME49811 ‘chip amp’. I will likely reuse my (modified) JLH Class-A for the tweeter, while overkill.

One thing I’m very uncertain is where to unbalance the signal. I’m currently doing it before the crossover (and therefor before the amplifiers) since it’s my understanding that matching parts is critical and very hard when purchasing small quantities.

Finally, the DSP board based on a DSP56371

It’s been a while but I’m very exited to tell you I’ve finished a small DSP board for a simple headphone amp. The original goal was to have a USB input in 16bit 48kHz and pass thought a DSP to “enhance” the sound before a tube power amplifier. I’ve been going mad trying to find a suitable DSP without committing too many hours; those DSP evaluation kits are not cheap.

That is until I found out about Freescale’s Soundbite which has decent inputs ADCs and output DACs. As a bonus they even have the Eagle files available (YES !)

My board is quite simple, two possible inputs:

  • PCM2707: USB to I2S
  • CS5346: 6 Single-Ended inputs with built-in PGA and MUX

The output is using a PCM4104: 24Bits with 118dB SNR 4-Channel Audio DAC.

The layout is still in review, a lot of thinking still has to be done, especially on the case and the power amp. However here is the board for your review and the Eagle files; please be aware that I make no guaranties this will work. If you like this you are free to buy me something from my Amazon wish list 🙂