I recently decided to convert some single ended Van Den Hul – The Thunderline cable which I was originally using as an interconnect a few years back in to a nice AES/EBU digital cable. There is a standard for the wiring of balanced cables but there is also a lot of other ways to wire a cable.

In the diagram above the top image shows the standard way to wire a balanced cable. This is Pin 2 Hot, Pin 3 Cold, and Pin 1 to Ground (GND). This works great for the standard digital applications and also for microphones where a hum and noise could be introduced in to the cable.

The wiring of audiophile cables is slightly different, traditionally you would leave the Ground (GND) connected only at the source end of the cable. This method provided the same screening as the standard method but reduces the chances of creating ground loops as the ground is disconnected. This probably doesn’t work too well for microphones where long lengths are used and there is a pretty good chance of noise being introduced.

My problem came when you have dual shields in a cable. Do you connect it the standard way and ignore a shield? Do you wire both shields together and follow the standard connect it at both ends? Or you could do the third option which is what I did, connect in the standard way but leave the outer second shield disconnected at the receiving end (Second Diagram).

If I were wiring for analog use then I would follow the audiophile method and leave the ground disconnected at one end, For all other uses including microphones, digital interconnects the method pictured above should be great!

Just a quick recap:

On Mac OS X 10.5 the default compiler is GCC 4.0.1, Apple does provide GCC 4.2.1 as part of the XCode Developer Tools releases for 10.5 but it isn’t setup as the default.

The main tools are located in /usr/bin. In this folder you will find both gcc 4.0 and 4.2 along with g++ 4.0 and 4.2. The commands gcc, g++, cc, and gcov are all symbolic links to the default 4.0 versions. To make 4.2 the default we just need to modify the symbolic links.

To do this we need to go in to the Terminal and issue the following commands:

Now you should have a complete working gcc 4.2.1 tool chain. If there is a problem you can verify the symbolic links are pointing at the correct targets by typing ls -l Hope this helps someone else.

I’ve been having some rather odd Safari problems today for the first time since I can remember. I really dig Safari, it’s everything I want in a browser and getting better with each release. I’ve been using Safari since the public beta back in January 2003 back when Mac OS X 10.2 was the main OS.

Anyway this afternoon I noticed that Safari kept using 100% CPU and becoming un responsive. I kept force quitting it but the problem kept coming back after about 10 mins. I tried the usual repair permissions, delete preferences and caches etc to no avail. I then thought I would try the Safari 4 Developer Preview, I downloaded it and installed it. It was perfectly stable and very fast, can’t wait for the finial release of that badboy! At this point I was still stumped as to why 3.2.1 was holding the CPU hostage but Safari 4 was fine. I uninstalled Safari 4 and reinstalled 3.2.1.. On restarting everything seemed fine but yet again it took all the CPU, back where I started. Just launching Safari and then closing the window and waiting would cause the CPU to be held hostage again.

I ran a filesystem trace to see what files Safari was touching, I basically sat and waited until the high CPU condition happened then took a look to see what files were accessed. After an hour of watching and timing the problem it seemed that Safari was continuously reading from the filesystem which is what was causing the massive CPU load. It was triggered by an unusual cache file hit, I did a check to see what network connections were established and saw some odd looking google server addresses, it then dawned on me that Safari 3.2 features anti-phishing protection that uses a blacklist provided by google.

This also explained why the the Safari 4 Developer Preview worked correctly as it doesn’t yet have the anti-phishing stuff. I turned off the anti-phishing stuff in Safari 3.2.1 and sure enough everything went back to normal. Me being me I was still bothered because why would it suddenly cause problems, it’s been working fine until today. I went back and took a look at the cache files it was using for the blacklists, I thought that corruption of some kind was most likely so I deleted them. I then re-enabled the anti-phishing mode in Safari 3.2.1, now been three hours and all is well again.

Relaunch Safari and all should be well. I couldn’t find any references to this problem online so I though I would post something.