Windows bug causes decoding performance with certain Soundcard Interfaces.

This is a great bug catch !! Kudos for blowing the whistle. I would bet there is quite a number of those early TI chips already in the installed base. While it may be understandable for MS to not revise current versions, I would hope they would fix it for Windows 10.

 

I am not sure it is a Windows Bug. It is a Windows design.

It is just the results of what happened to the Windows Audio Mixer, when they decided to hose it and make it PNP for you.

Enjoy the new contacts.

 

FYI - see below as copied from the N1MM Yahoo Group. It seems Joe Subich, W4TV, has a different take and more info on this issue. And allegedly a software upgrade to a later version of Windows is a solution. 73 de John WØPV

Re: [RTTY] Reddit Article Showing Windows 7 and certain USB Audio Chipbug

• Joe Subich, W4TV
  Today at 9:43 AM
  
  The "bug report" is highly inaccurate and the instruction to
  set the "microphone" level to 100% is completely *wrong*.
  
  Right click on the microphone slider and set the display for
  *decibels*. In Windows 7 the microphone slider scale will range
  from -196.0 dB at 0 to +30 dB at 100% while in Windows 8.1
  the scale will be -96.0 dB to +30.0 dB.
  
  Negative gain levels represent attenuation between the input of the
  CODEC and the analog to digital converter while positive gain levels
  represent excess gain. Sands is completely *wrong* when he says any
  value below 100% represents attenuation. In fact, any value above
  0.0 dB represents *GAIN* in the CODEC.
  
  There is one "bug" in Windows 7 and prior - the USB Audio Class
  driver will reset the gain of the endpoint (input) on any CODEC
  that has a *single input identified as "microphone"* every time
  the CODEC is opened. This means Windows sets some members of the
  TI PCM29xx family to +30 dB on each use. *THIS BUG HAS BEEN FIXED*
  in Windows 8 and later.
  
  The best recommendation for setting USB levels for any "microphone"
  input supported by the Windows "USB Audio Class" driver is:
  
  - start the program that uses the sound card in question
  - go to Control Panel | Sound | Recording tab, double click on
  Microphone - USB Audio Codec device
  - on the Levels tab, right click on the microphone slider and
  set the units to *dB*
  - adjust the slider for 0.0 dB +/- 0.5 dB - this will typically
  be 3% in Windows 7 and 54% in Windows 8.1
  - tune to strong carrier (S9+)
  - watch VU meter on Recording tab and adjust output level from the
  radio (typically the RX pot on the interface - "Line Out" in the
  K3/K3S) to 2 bars below full scale. If it not possible to reach
  2 bars below full scale (the K3/K3S has plenty of excess drive)
  increase the level slider slightly until signal is no more than
  2 bars below full scale.
  
  I no longer have working XP or Vista systems and do not recommend
  the use of obsolete operating systems. However, the same procedure
  (adjust for 0.0 +/- 0.5 dB) should also work with XP and Vista to
  prevent overdrive and clipping there.
  
  In any operating system, a 0 dB input gain setting will provide the
  best balance of dynamic range and sensitivity in a sound card with
  properly designed audio input circuits. Audio from the transceiver
  should be set so the no-signal "sky noise" is about 15 dB above the
  noise floor of the CODEC and the strongest signals no more than "2
  bars" below the top of the "VU Meter" to prevent clipping.
  
  It may be more difficult to properly adjust levels in some Icom
  transceivers that offer no hardware control of the audio levels
  into the PCM29xx family than in external interfaces or the Kenwood
  (and Elecraft K3S) transceivers that *do* provide control over the
  audio level to the CODEC.
  
  This "bug" *IS* a compelling reason to upgrade to Windows 8.1 or
  Windows 10!
  
  73,
  
  ... Joe, W4TV

 

Then how come many people with Windows 8.X and that have the PCI29XX with the old rev are experiencing the same issue in the video?

He says KD9DAL is wrong but then he acknowledges that there is a bug so KD9DAL is technically not wrong. I can't comment on the suggested settings that the author suggested but it's better than trying to decode a distorted signal. I am sure many of us were unware of the issue since the majority of us don't go collecting the white papers for each IC in our equipment. The TI white sheet for the revs of chips don't list Win7 as a supported OS. We just assume it would work. It might have worked with XP but times have changed and now it doesn't work but by looking at the comments on here, reddit and youtube, it appears many people were unaware.

So at least it's brought to your attention. You can decided to check it out, ignore it or try something out. Worst case is that you have to redo your audio settings. It won't brick it.

 

That is a bit of a stretch.

Why mess up a good OS when a small tweak or different mixer can fix it ?

Windows 8.1 or Windows 10 does not protect from operator error.

 

Thanks for the info! Unknowingly I think I worked around it by using a second soundcard.
I started with my FT-991 connected through the USB. Had a lot of trouble getting this to
work. So I added a Signalink box. Windows sees two audio codexs, which I now realize
are the radio directly, and the Signalink. I've been using the Signalink, which is the second
codex for me. Somehow the levels seem fine on this second device.

 

Thanks Joe, W4TV

 

Well almost no one mention that the Icom 9100 is having this bug as well.
I follow the recommendations on the YouTube video and in my case it didn't work.
Then i did the method of Joe - W4TV described here and this time works 100%.
I will check later the difference on the air using HDR software. So far so good.
Also Thanks to KD9DAL to let everyone knows about this SUPERBUG.

Thanks Joe, W4TV

 

Heh, this guy is a little confused here, he should have watched the full video. The "fix" he recommends of lowering the slider to read as close to 0db as possible does not fix the distortion, it simply lowers the amplitude of the already clipped waveform. It would behave as he states on a clean system where this bug does not effect the enumerated input, but that's not the case with these chipsets. I'll provide screenshots below. It's not as simple as "It's enumerated as a microphone device, so it sets the slider at +30db of gain, and reducing this slider to 0db clears this gain", at least not on windows 7. At least on my windows 7 test system, the gain is getting applied before the slider and regardless of it's setting as shown below.

The "setting the level slider at 100% for 0db gain is totally incorrect" paragraph of his would be correct, if the device is seen as a microphone input, which is the bug. After we clear the bug as demonstrated in the video, the device is now treated as a line in device, and 100% on the slider is most certainly 0db gain, even if the UI is still treating it as a microphone input and reading +30. This is demonstrated plain as day by feeding a reference signal into a PCM290x chip (TI specifies a given full scale input voltage to correlate to full scale dbFS output, very easy to test) and measuring the output full scale as both a microphone and line in device. TI's own white paper has graphs showing very clearly the slider values in windows when treated as a line in device, 100% is 0db gain as instructed in the video.

His fix was tried at 11:24 in the video, I can't blame him if he was too lazy to make it this far in as it is certainly a long video. you can see as I lower the slider value to as close to 0db actual reading as I can get it (about 4% up), we've certainly lowered the amplitude of the waveform as W4TV states. However you can see we are simply attenuating the waveform after erroneous gain has been applied, we are not recovering any clipped parts of the waveform -

After not clearing the bug, therefore leaving it enumerated as a microphone device, and setting the slider to Joe's recommendation of reading as close to 0db as possible (-0.4db is as close as windows will let you get, about 4% on the slider) -






You can see it has certainly been lowered in amplitude as Joe states, but look at these lovely cut tops.


Here's the exact same signal directly from my radio unchanged, except now we've cleared the bug with the workaround and gotten rid of the gain before it's ever applied, leaving the slider at 100%, meaning 0db, as it's now seen as a line in device -




I'll let you personally decide which one more accurately represents the sine coming from your radio, I don't mean to get into any debate with Joe. The above results are reproducible on W7 with any software scope of your choosing, or a hardeare scope if you want to se up an audio program to pipe out the incoming audio from your radio back out to a soundcard output to your scope. Just as I do in real life, I simply test and test and test some more and then adjust my operating practices based on the data produced, not by following "Microsofts recommended setting of microphones" on a system with a glaring bug causing microphone enumeration to behave incorrectly. This is on a windows 7 system, it's entirely possible lowering the slider on w8/w10 DOES clear the erroneous gain in the first place, but I don't have a system to thoroughly test on, I have to rely on 3rd party reports for those OS's.

Hope that clears everything up!

 

The bug exists in Win8.1 and Win10 still too. I just confirmed that the bug is real on my spare SignaLink and tested on two different laptops. I will be giving a PSA at my next club meeting to teach people about this horrible bug.

After looking at the problem, I think the issue lands with the manufacturer, not TI or Microsoft. The companies that use the chip should have switched chips in their product as soon as it warned by TI about the issue with W7+, which seems like happened long ago. Unacceptable! I feel so sorry for those with radios with this chip stuck internally. Kudos to Elecraft for paying attention to the little things. I'm betting the Big 3, and perhaps TigerTronics did not know about this issue. I don't expect the Big 3 to do anything, but TigerTronics may. I wonder if anyone has contacted them about it? I'd be shocked if no one has yet.

Another reason I'm glad I've been using FlexRadio SDR's for the last 10 years.

 

I Updated the Silicon Labs CP210X USB to UART Bridge driver to version 6.7 witch is newer than the one provided by Icom.
I set the microphone slider at 2% and so far no distortions notice in the scope, above 4% i start notice the clipping. Im running Zelscope and my pc is windows 7 x64 and Icom 9100

73

 

I did contact TigerTronics via their support contact form and received the following reply: "Thank you for your email. Regarding your question about the SignaLink, we were just made aware of this issue yesterday and we're currently investigating. It'll probably be a while before that's done and we have anything more to add. " So stay tuned for further developments.

 

AF4RK - I have been using an Icom 7100 on PSK, RTTY and JT65 since the radio first came out with no problems. Windows 7 Home Premium. I followed these instructions and PSK promptly stopped working in HRD! I checked my levels. I am using 30% in ACC/USB AF Level. No problems at all. If you own an Icom 7100, please ignore all of this nonsense! At least for Windows 7

 

I love how people think they are immune. This isn't an ego thing and is not a hit or miss thing here guys. If your radio uses the chip referenced (and the IC-7100 does), it will exhibit this issue in W7+. There is no exception to this. Those who also say it was working fine before are just denying the facts. The robustness of the digital protocol used is why it worked even in the presence of heavy distortion. If you spend the time to resolve the issue, you will see that decodes that you may have missed before. But how do you prove a negative? The facts are there. TI even said it in their PDF:

http://www.ti.com/lit/an/sbfa020/sbfa020.pdf

Also, this only impacts receive, not transmit.

 

Using a different driver on your USB / Serial chip (adapter) will make zero difference on resolving the issue. The distortion is still there. You are just reducing the input levels so low that square and sine waves look the same due to quantization limitations.