Signalink RX Performance Fix

Reddit user Fohdeesha posted earlier in the AmateurRadio subreddit about the issue of Windows adding unnecessary digital gain to audio levels when using a USB sound device like a Signalink interface. He posted a workaround for the time being but hopefully now that this issue has been found it can be patched soon. The article is below and you can find the original link with comments on Reddit here.

Edited this for brevity and clarity (tried to, anyway). There’s a bug with the USB audio chipset used in many ham radio sound interfaces that occurs in windows vista and later. The affected chipset is the TI PCM2900 series, pre-C revisions. A non conclusive list of devices using this chip line are all Icoms with built in USB sound interfaces(7100/7200), all Kenwoods with built in usb sound interfaces (590), and all Signalinks. If you have one of these devices, and are on windows vista or later, your performance is reduced due to this bug even if you think it’s working fine. Wait until you see your performance afterwards 🙂 This is confirmed by Texas Instruments, who never recommended this chipset for use on windows Vista and later in the first place, and also tested with more than 15 hams who gained massive receive performance after the fix.

The bug is very odd and has some quirks that bring it back very often even after the fix so I made a detailed video linked below demonstrating the bug, the fix, and showing real measurements of the affected audio on a scope and several meters, and also demonstrating how to properly level your audio in the analog domain and in windows for maximum dynamic range and minimal noise after you fix the bug.

 

The main video – Huge bug + fix for amateur radio digital modes (audio levels)

 

The Bug: There’s been a few complaints that the bug and fix are only outlined in video form (even if it’s in the first 3 minutes), so I’m writing a text description here. Keep in mind there are several quirks with this that would take a long time to type out so I still recommend watching the video to be completely informed, but in case not: The bug is that this line of TI chipsets identify themselves to windows vista and later as microphone devices via the Input Terminal String, even though they are being used as Line In devices. This makes windows add 30db to 50db of gain digitally to the input, clipping your incoming signal. A lot of people I’ve worked with have “worked around” this bug without knowing it by lowering the level slider in windows recording properties panel to very low levels, or by turning their signalink RX knob nearly all the way down, or a combination of both. This is very bad, it reduces the dynamic range of your incoming signal pushing it into the noise floor, and most importantly, does not solve the already clipped and distorted waveform due to the unnecessarily added gain. Nothing will return your incoming signal to the pure undistorted sine wave besides the “fix” outlined below, even if you think it’s working well enough now. Trust me, we’ve verified with 15+ people on different setups and radios that performance on modes like JT will double.

 

The Fix: Thankfully there is some way around this to force windows to enumerate the device as a non-microphone device, therefore not adding the massive amounts of digital gain to your already properly leveled signal. In Windows control panel, click sound. Click on the recording tab. Keep an eye on the green level meter next to your radio device. On the radio device, click properties, then go to the levels tab. Make sure this level setting is all the way at 100. Anything less than this is simply adding digital attenuation to your signal, which is bad. You want to make sure your signalink rx knob is about halfway, or on kenwoods, set the usb output menu setting to around 5. Since you have this bug you have most likely cranked all these way down. To see the bug disappear you need to turn them back up to where they should be. Since you have this bug, the green level meter in the other window is probably maxed out now. It will read normally once we clear the bug. Now click to the Advanced tab – the fix is to toggle the channel count. If you are currently on 1 channel, switch to a 2 channel setting and hit Apply. You will watch the green level meter drop to half of what it was or less. That’s the bug disappearing. You can now set your signalink or radio output level to what it should be and are no longer forced to set them to extremely low levels. You can toggle the channel count back to what it originally was now and hit apply once more. Here’s the downside: The gain bug appears every time the device goes idle, meaning no applications are using it. So in the Sound properties pane with the level meters, if you simply click away from the recording tab to “Sounds” tab and back, you will see on the meter the bug has reappeared. Since discovering this, I simply leave the windows Sound pane open on the recording tab in the corner of my desktop, this way it keeps the device from ever going idle and the bug reappearing, and also gives me a visual indication if the bug does reappear.

 

There are many more subtleties to this bug that are covered in the video, complete with oscilloscope measurements showing that simply lowering the level slider or your signalink all the way down does not fix the distorted audio and still negatively affects your digital performance. There is also some thorough advice on the setting of levels with signalinks, kenwoods, icoms, and wsjt-x. Everyone I have tested with that had the patience to run through the entire video and following its procedure for setting levels reported massive improvements in decodes. If the explanation above didn’t make sense or you’re confused or having doubts, I recommend watching it as it walks you through the procedure

 

I’d like to give a big thanks to all the members of FBOM that helped me test and reproduce this several late nights in a row as well as verifying the fix.

The interfaces affected listed above are only the ones I can guarantee 100% as I personally tested them on multiple systems. It’s entirely possible Yaesus with usb audio, Rigblasters, etc suffer from this as well, but I don’t have them to test. If you do, please run through the video/fix and leave a comment.

Here is a whitepaper from TI outlining the issue and why they clearly do not recommend these revisions of chips for use on windows vista or later. In my opinion it was a huge oversight to source this chip line on devices like Kenwoods and Icoms where Windows Vista and newer were already mainstream before sales and much later revisions of this chip were available. – Whitepaper

Important takeaway from the paper above – “On the PCM290xB series, the Microphone is identified as the input terminal descriptor. Thus, even though the PCM290xB does not provide a gain control function such as a programmable gain amplifier (PGA), Vista and Windows 7 both automatically give a positive gain on the volume control panel. As a result, the input signal will saturate at even slight recording volume increases”

Here is a thread from 2010 of several developers complaining of this exact issue with their designs –Forum Thread

 

Small things I forgot to mention in the video:

• As previously mentioned the bug is caused by the older revisions of these chips being enumerated as microphone input devices in windows vista and later. It is entirely possible to fix this in software with a modified driver, and someone on TI’s forum wrote a temporary one and sent it in. TI said they would evaluate the fix and report back, but never did, which was 5 years ago.
• TI does link a separate driver of their own called the “audio filter driver”, but you do not want this. The chips previously exhibited 1khz noise in certain operating conditions that don’t affect us (8khz sample rate). The filter driver is identical to the MS driver (and still has the bug) except it has a digital 1khz notch filter to try to remove this noise, which is very bad for digital modes.

Thanks! Feel free to post this around to the mailing lists and ham groups, everyone I’ve tested with couldn’t believe how much of a difference they saw. I ask that you link to this reddit post and not directly to the video so they can see all the information and reports below