When I was at uni, I had a pretty nice little audio setup. It consisted of the ever-popular Creative Live! Platinum 5.1 audio card (with the nice front panel inputs) combined with a 4 speaker Cambridge Soundworks woofer / tweeter setup.

Not exactly a sound engineering setup, however it sounded great to me. The best feature was that I could have digital audio thanks to the Creative DIN connection from my Soundblaster to the speakers. This meant everything sounded crystal clear, with no cable noise or anything (you could turn the volume all the way up without a hint of a buzz).

The Soundblaster also had some cool features for the aspiring young artist that I was including sound fonts and midi-input / outputs that worked nicely with my Yamaha natural action electric piano. It was just a pity the card wasn’t that good from a recording point of view and there was a lot of noise on my tracks. Also, I didn’t really have the required talent to become anything much of a musician.

Anyway, I recently upgraded to a new computer with an on-board Realtek soundcard. Unfortunately the drivers for the two cards didn’t play too well together and I had to make the difficult decision to remove my ageing Soundblaster. This of course had the effect that I could no longer use the proprietary digital connection on my speakers and they therefore started to sound muddy and lifeless. That was until I did some research on the connection and found that the Creative DIN connection was in fact a bunch of SPDIF connections. I also came across a cable that was packaged with the speakers to take the digital connection from the little yellow 3.5mm jack on the top of most Soundblasters.

So, it was just a matter of getting a Male-RCA to Female-3.5mm converter to plug into the Realtek SPDIF and now I have nice digital sound from my new computer!! It’s so good to hear every imperfection in the MP3s. I know people are looking at me strangely, but I found it exciting. The rear speakers are not working just yet, but I’ll get to them soon.

Okay, so you have a server that hosts a variety of PHP applications and you want to have a look at the emails it is sending out to make sure none of them are dreaded form spam. Sounds tough eh? Thankfully there is a little trick we can play on Linux servers to grab and track the emails PHP is sending out.

Under the mail section in php.ini, there is a little variable called sendmail_path. This is where you can specify the sendmail command and any included parameters (useful if you want to have a default from address in your emails). The trick is to simply change this to our own script (executable by apache) that will log the email and forward it through to the recipient.

Unfortunately passing around STDIN can be a little more difficult that it first seems and it was too much for my noob bash skilz. So, I reverted to Perl. One thing I like about Perl is the relatively ease in which you can write to pipes, but I digress. Here is the logger script: #!/usr/bin/perl # the log file (append mode) open (MYFILE, '>>/tmp/sentmail.txt'); # our pipe to sendmail open (MAILOUT, '|/usr/sbin/sendmail -t -i'); # grab the content from STDIN @lines=(<>); # write the current timestamp to the file # this is critical for matching log entries print MYFILE `date`; # write the input to the file print MYFILE @lines; # write the input to sendmail print MAILOUT @lines; # a nice separator for the log file print MYFILE "-------------END---------------\n"; # close our file handles close (MYFILE); close (MAILOUT);

In this case I have my log file at /tmp/sentmail.txt

To use, simply save it in a directory that is accessible by the apache user and chmod +x it to make it executable. Then change the sendmail_path in php.ini to point to the script rather than sendmail. Of course, you should test it by sending yourself an email through the mail( ) function and check the apache error_log for any issues.

Okay, I’m sure I’m not the only person to run into this issue. If you are trying to enable TCP/IP on Microsoft SQL Server Express 2005 you have to jump through a couple of hoops to get it working.

First you have to enable TCP/IP in the SQL Server Configuration Manager like so:

You would think that this is enough no? After enabling this it still doesn’t work.

Tip: you can quickly check to see if the server is listening for connections by opening a command line and typing:

telnet localhost 1433

If you connect and the command window goes blank, you’re in business; otherwise it will just sit there and eventually timeout.

Anyway, the secret to get this working is to specify a port to listen to for each of the TCP interfaces. For some reason there is no port in the interfaces by default, which caused me all sorts of grief. There is a bunch of interfaces, but you have to add 1433 to each, like so:

After this, you should be able to restart and everything will be sweet.

If you are trying to connect using PHP on windows, you may need to replace your copy ntwdblib.dll that came with PHP with an alternate version, do a search here: http://webzila.com/?wz=dll for ntwdblib.dll. On WAMP, you will need to replace this in 2 places: c:\wamp\php and c:\wamp\Apache2\bin. You may also need to use a special syntax for connecting, I used “localhost,1433″ as the server address and that worked for me. See the manual for more info.