Riccardo Macri's Blog

My Linksys VOIP ATA was acting up, refusing to call one of my SIP services even though it claimed it was registered. I was on firmware 5.1.10 which has been the latest for a few years. Searching the internets for news of any update, I stumbled on the unfortunate tales of promises unfulfilled, as expressed in these threads:

http://forums.whirlpool.net.au/forum-replies.cfm?t=1130617
right through to
http://forums.whirlpool.net.au/forum-replies.cfm?t=1544801

and then ending up here
https://supportforums.cisco.com/thread/2035426

Basically, I’m facing the same problem as many. The ATA works fine until you make a call through your PSTN connection. This switches the SIP codec to G711u and locks it there. If you have a SIP service that demands something different (G711a in my case), you’re out of luck and the only option is to reboot the ATA. Any options you set are disregarded after the PSTN call.

I learnt from the discussions linked above that for three years, a group of dedicated owners have been chasing Cisco for a firmware fix. Support promised that the fix was in testing for years, continually pushing forward the release deadline. The last promise was US Summer 2011, and thats long gone now.

As someone who has worked for the last 22 years on many projects (including commercial simulation, realtime systems and satellite modems) with a release cycle measured in days or weeks, all I can say is that it was good to be made aware of this sorry 3 year saga before I upgraded the ATA with something new.

For now I’ve downgraded it to an earlier firmware version (5.1.7) which doesn’t have the annoying and stupid bug.

The not so new EEE PC was experiencing intermittently stuttery audio when playing a Flash based radio stream. This was strange as it coped fine with MP3 and WMV streams, even with video. It wasn’t a buffering issue. The audio had very short glitches – the kind of thing that happens when a device driver locks the bus too long (he says, having worked on a Linux audio driver a few years back).

The wireless drivers were up to date and the wireless hardware configured to use CAM mode (a problem that plagued the ION HTPC when I first installed XP on it). Power management settings were set for high performance.

I also determined it was no where near running out of CPU, sitting at only 10% when playing the stream. After updating drivers, firmware and minimising the configuration as much as I could, I started thinking it might be network related.

I set up a regular ping of length 8192 bytes from my workstation to the EEE so I could see what network performance was like. I was only half surprised to find that ping times were all over the place, with some peaks in the 100s of ms. With the audio streaming, the high peaks corresponded with glitches in the audio.

With it happening even when close to the WNDR3700 wireless AP, it wasn’t a signal level problem. It was connecting at 130mbit (N speed) on the 2.4GHz band.

I switched the router to limit 2.4GHz to 54mbit and the audio problem went away. Ping times to the EEE became a solid 4ms.

Looks like its a combination of crappy behaviour for the EEE’s wireless driver in “N” mode and the Flash Player using a very short audio buffer, making it easy to underrun audio playback. Fortunately I can handle the slower 2.4GHz network since I run a separate 5GHz network for the HTPC.

I’ve discovered a unique hack with my Samsung Galaxy Note phone.

It was playing an audio podcast and sitting next to an AM/FM clock radio (in AM mode). I tried tuning the radio around just to see what the phones digital interference sounded like.

To my amazement I found I could tune in the audio playing on the phone, very clearly, in multiple places on the dial. Testing with a radio with a digital tuner,  I found 855KHz was a good spot.

It works best if the audio level on the phone is quite low and the screen is off. The AM radio makes a nifty audio power amp. Its not perfect, if the charger is plugged in things get really noisy … and when the phone polls the GSM network it makes the radio buzz, as you’d expect if you’ve ever left a digital phone next to a radio.

I’m guessing the phone uses a switchmode audio power amp which happens to make an effective very short range transmitter.

I wanted to wirelessly share a network my laptop was physically connected to, so I thought I’d give WinXP’s adapter bridging a try, bridging the wireless and wired network devices.

It seemed to work – I set my computer to create an adhoc network (enabling the option to always connect).  The other computer saw the adhoc network and got an address from DHCP supplied from the LAN I was connecting to… but it couldn’t access the network and was unpingable from my laptop.

Research revealed the problem is that my laptop’s WLAN driver (Intel) reports that it supports “promiscuous mode” when it doesn’t. This is resolveable by forcing Windows to use a workaround for when promiscuous mode isn’t available in an adapter. This is done as follows.

(in cmd)
netsh bridge show adapter

This should show the network devices in the bridge. Use the ID of the wireless device, mine was 1. Then issue:

netsh bridge set adapter 1 enable

With this, the other compouter was able to access the LAN via the bridged WLAN.

It should now work (dont think I had to reboot).

Don’t be disappointed to see “Not Connected” on the Wireless Networks list. The status doesn’t seem properly reported. Also its WEP only do keep your shares locked down.

Thought I’d update the 3 year old video driver on my 3 year old ATI HD3650, which does the job on my business-use VM running machine under XP64.

Less than delighted to find VMs crashing the host when I switch them to full screen console mode, as I do when I use Emacs.

Clearly a case of minimal testing of the latest shiny drivers (11-5_xp64_dd_ccc_ocl, April 2011 build) with older hardware/OS configurations.

Back to the old driver. The new driver hadn’t fixed a minor mouse issue with VMWare anyway.

I thought it would be interesting to have a small linux VM running on the ION HTPC. Nothing heavy, just an SSH server. I installed VMWare player from my 7.1 VMWare Workstation install and copied across my linux VM.

It booted but there was a bizarre networking problem. I could ping from the guest (VM) to other machines on my network except its host, for which it would report destination unreachable. The host could ping it and I discovered that after the host pinged the guest, the guest could ping the host, for a while. Then it became “unreachable” again. It wasn’t a host firewall problem.

The same VM was fine on my main PC, both setups were using a bridged network. The only difference was that the ION is using a wireless network.

Some searching found this very useful thread:

http://communities.vmware.com/thread/211266

It turns out that the guest is having problems finding routing information at the ethernet level. It does not know how to reach the host which is sharing the same network adapter. The guest sends out an arp request but the response it gets has the IP address of the host, probably related to them being bridged on the same device on a wireless network.

The solution is simple, in rc.local add an ‘arp’ command to create an association between the host’s IP address and its adapter MAC.

This worked for me:
arp -s xxx.xxx.xxx.xxx yy:yy:yy:yy:yy:yy
where xxx.xxx.xxx.xxx is the IP address of the host and yy:yy:yy:yy:yy:yy is the MAC address of the host.

Interestingly, if I used the MAC address of the guest, it also worked! Not surprising since host and guest are bridged. But pings were about 150us quicker if I used the host MAC address.

Speaking of speed, given the ION is no speed demon and has no hardware VM support, the VM is not exactly fast. It feels like the speed I used to get with VMs on a PIII; good enough for lightweight linux stuff and data rates < 2MB/second.

The ION 330 HTPC I put together at the beginning of the year is going quite well. Here are some follow up items of interest on it.

Remote Control

I had a DVICO IR receiver that had come with one of my previous HTPC’s tuner cards. I found that the open source software EventGhost works quite well with it.

For my remote to be reliable I found it best to run the HID plugin for the DVICO receiver in raw mode, and only used “initial button press” events.

NVIDIA ION driver leak

I was bemused to find a process was using over 50000 handles after only a few days uptime! It ended up being an NVIDIA component used for stereoscopic 3D display, nvSCPAPISvr.exe. This page has a good tear down of the problem. Its probably fixed but I just set the “NVIDIA Stereoscopic 3D Driver Service” to “Manual” start, what a waste running something so specialised on every install.

HDMI

I initially connected the ION to my tele using VGA and a separate audio cable. I upgraded to a HDMI cable and its worked great for both sound and picture. There is a slight delay in audio starting so short sounds in explorer get missed but this isn’t a problem at all once in ZoomPlayer.

Having achieved good video playback on my new ION 330 HTPC, the next step was to get WebScheduler running. Being a 32 bit app that had to work with 64 bit BDA drivers for the TV tuner cards, I was concerned about it all working properly.

I started with WebScheduler 4.0.14, the last “free” version before it had gone commercial a few years back. This version has served me well under XP32. It installed without a hitch and ran fine, the only glitch I noticed was that the taskbar icon didn’t reflect when WebScheduler was recording.

It recorded files fine and I left it running about a week while I worked on other stuff. It wasn’t until the weekend that I discovered that the recordings it had made were unplayable!

I determined the recordings were not total trash, just Haali Media Splitter didn’t want to know about them. Using the Gabest splitter or ProjectX to demux them both worked.

So it seemed something was different between the files recorded under XP32 and Win7 x64, both done with the same version of WebScheduler and the kWorld USB Dual DTV Tuner stick capture hardware.

Having determined I was on the latest driver for the KWorld tuner, I was resigned to having to try Win7 x86, but before I did, I thought I’d try the latest version of WebScheduler as it had become open source again. Its now known as TV Scheduler Pro, by Blue Bit Software.

To my total delight, the recordings came good. I was able to export and reimport my schedule match lists between the 2 versions, which happily co-existed on the same machine for a while while I transitioned. The new version has some nice new features and I’m glad its recording properly under the new operating system.

So now recording and playback is in place on the new HTPC.

Its over 4 years since I built the HTPC to record and watch DTV and given it was P4 based, an upgrade was well overdue. I bought an ASRock ION 330 to serve as a replacement. As if it knew, within a few days of acquiring the ION, the 300GB WD HDD on the old HTPC started reporting CRC errors.

I decided to go with a low power solution rather than eusing the nice Accent HT400 HTPC case (and its iMon remote control), mainly because power saving is a bit of an issue now. This meant buying a new DTV TV tuner solution. I went with the KWorld Dual DVB USB tuner. It is based on the ITETech AF9015 and even comes with a worthless remote control that looks like a calculator.

I was already forewarned that the application software (tvMe) that come with the KWorld (a version 1.0) was bad, but I had to install it on a test system just to see how unbelievably bad it was. It needed dotNET – this should have been a warning. The software looked like someone’s second programming attempt, you know the program you write after “Hello World”. It was badly broken but did indicate the tuner was working. The software stayed installed only long enough for me to notice that the tray icon it installed had the tool tip “My App”. Hello World indeed.

All I wanted from the KWorld TV stick was a functional BDA driver, and after a few days running under XP32 with WebScheduler 4.0.14 I was convinced it would be a viable DTV device (actually, a pair of them since its dual tuner).

Next it was time to setup the ION. I’d bought 4GB of RAM for it so I thought I’d give Windows 7 x64 a go. Whilst XP would have suited my needs, I thought the EVR rendering in Windows 7 would be useful.

The Atom 330 which powers the ION is not exactly a powerhouse but having the NVidia ION able to accellerate video rendering is what makes the ION 330 a winner for HTPC purposes.

My favorite video player after all these years is still ZoomPlayer so the next step was establishing how well a 32 bit app with all its 32 bit codecs would work under Window 7 x64. It turns out that ZoomPlayer 7 works fabulously, but now time came to get the codecs set up right.

Firstly, MPEG2 TS playback. I’ve yet to top the combination of Haali Media Splitter and DScalar for playback of raw TV recordings (TS files). It gives me silky smooth playback of off the air interlaced TV. Other splitters/decoders work but either have laggy response to fast forward/rewind, horrible seeking delays or bad video quality especially for motion. I dont think DScaler is doing acceleration, but it copes with hi-def MPEG2 at about 30% CPU utilisation.

Next was testing some H264 1080P trailers. FFDshow woeked but was maxing out all 4 “processors” on the Atom 330 (its actually two cores each with hyperthreading). So it was time to choose an accelerated video decoder. Supposedly Win7 provides one but the video decoder from the Media Player Classic Home Cinema (MPC-HC) open source project trumps everything else out there for quality.

Downloading MPC-HC codecs, I was faced with the decision of 32 or 64 bit. Given my application is 32 bit but my operating system is 64, I wasn’t exactly sure what I wanted, but my guess of using the 32 bit codec paid off.

The process involved just the file MPCVideoDecoder.ax, put it somewhere and register it with “regsvr32″. This worked, once I learned the Win7 trick of opening an administrative console with ctrl-shift-enter when you type cmd into the search field.

Back in ZoomPlayer, in the Smart Play video decoder configuartion for “H264″, I had to select advanced editing and manually browse the list of codecs to select it. It comes up as MPCVideoDecoder. I selected the EVR renderer as well.

With this in place ZP plays 1080P H264 with 10% CPU utilisation, amazing.

Its worth noting, I’m looking at XBMC as well, either as the front end to ZP or standalone once video acceleration support becomes mainstream for the Windows version.

It can be a nuisance transferring windows to a new HDD for a system when that windows has previously seen that drive as an external.

It boots OK but then has the wrong drive letter for the user profile so it can’t login, since Windows “knows” the drive by the letter it was last used as, not the default C:.

In this case I was updating a laptop with a bigger drive, which I’d previously used as an external USB drive for it.

In this past I’ve used a BartPE XP boot CD to get into it but in this case I got it to allow login by plugging in the original drive as the USB drive. It could now find its profile and let me in.

Then in regedit I removed everything in HKLM\System\MountedDevices (maybe best to just remove the \DosDevices only) then it booted fine from the internal drive.