Harrison Pham

I'm starting a new project where I'll be making a standalone internet mp3 player. I listen to internet radio stations almost all the time and would love to have a way to enjoy those stations without my computer.

I've just ordered a VS1011 mp3 decoder breakout board from Sparkfun. I plan on connecting this up to a Propeller Chip running my custom TCP/IP stack, PropTCP. The Propeller will buffer the audio and feed the raw mp3 stream to the decoder chip.

The overall bandwidth required by this application is pretty low. A normal 96kbps Shoutcast stream only requires 12Kbytes/sec. A small 256kbit SPI SRAM chip should provide a nice 2.5 second buffer in case there is packet loss or severe network latency.

I also did a bit of research on the Shoutcast stream format and found out it isn't very well documented. Luckily it is quite simple and numerous people have 'reverse engineered' it. The stream itself runs on a HTTP-like protocol and uses embedded metadata sent every X bytes. More information about it can be found here.

I usually bash Comcast a lot because of their poor support and very weird package offerings. But today they formally announced an all-market speed increase for their two main packages. The 6000/384kbps package becomes 6000/1000kbps while the 8000/768kbps becomes 8000/2000kbps. This is an amazing increase, and probably took them a really long time to get ready for.

This brings them pretty much up to par with AT&T's DSL and Uverse offerings. I really felt that AT&T had the upper hand with their new VDSL deployments since it offered the fastest speeds for a really competitive price. They only held this status for a year before Comcast announced this speed increase.

I actually got this update on Monday when my modem rebooted as a result of the new config file push. I figured it was just one of Comcast's various random network updates and didn't check into it. I only noticed that they had increased the speeds when I read a news post on DSLReports. I got really excited and proceeded to test the supposed speed increase. Comcast disabled config file names in my modem log so I have to use a more scientific method of finding out my provisioned speed (speed testing).

I used WinSCP to upload a 3GB CentOS ISO to a server in Atlanta, GA and used SNMP to monitor my outbound connection speed. I was very pleased to see the speed stayed between 850 - 980kbps for the 1 hour I ran the test. In fact, I could upload at this speed without causing any delays to my other internet traffic. My gaming and VOIP packets had no added latency, which surprised me because I used to get +500ms latency in the past with my 384kbps upload provisioning.

I'm very pleased right now. I was very annoyed in the past about the lack of good upload speeds. Now I don't have anything else to complain about (that is, until I find a use for all this new found upload bandwidth). Maybe Comcast will push out a bump in the near future...

I have an old 1.8GHz Sony Vaio Desktop that uses a software controlled fan. Sony apparently thought it would be wise to just do everything in software, and would require you to install a Windows service to control the fans. The service was apparently a hack because it doesn't monitor the system temperatures. This lead to all sorts of system stability problems when the computer started getting older.

I've recently built a new computer to replace this aging desktop. I didn't want to waste good hardware so I decided to turn the old Vaio into a linux server.

I installed CentOS (which took ages because the dvd drive was all messed up). During the install, I noticed that the fan was insanely loud. The power supply fan combined with the cpu fan created a horrid noise that could be heard 2 rooms away. A quick search on google confirmed that old Vaios exhibited this fan problem. A few posts noted using something called pwmconfig. A little more research showed that this was a smart fan control configuration script that comes with lm_sensors.

I spent a while messing around with pwmconfig. The script had a flaw in it (it used tempfile instead of mktemp). A quick edit fixed that problem. I eventually gave up messing with smart fan control because I figured I could just use a fixed fan speed (like the method Sony decided to use).

So here is how I did it:

Install lmsensors:
yum install lm_sensors

Detect sensors:
sensors-detect

Run pwmconfig to get fan statistics (note which pwm channel controls which fan):
pwmconfig

Write a script to force fan speeds:

# Makes fan silentish
echo "Setting fan speeds...."
echo "125" > /sys/bus/i2c/devices/9191-0290/pwm1 # cpu fan
echo "75" > /sys/bus/i2c/devices/9191-0290/pwm2 # ps fan

Add the script to autostart on boot (I use console only, hence runlevel 3):
ln -s /root/fanquiet.sh /etc/rc3.d/S99fanquiet

A quick reboot of the system and everything should be working. If it doesn't work at all (no fans changing speeds), then you may need to check your i2c devices path, and make sure the lmsensors service is running.