Thursday, January 10, 2013

An interesting discovery about sound cards

CheckSR result at 48kHz with internal sound card
I have several radios connected to my shack PC. For the audio interfacing I have several sound cards or sound devices since most of them are not internal cards but use USB ports. I wanted to make sure the rig I mostly use for digimodes used the best sound card I had so I thought I would do some tests.

Some people believe it's better to use a high end sound card for radio work. I don't think there is any benefit for HF use as the noise level will be much higher than even the poorest sound card. There is no advantage to using a device capable of more than 48kHz sample rate unless you are using SDR software and need the extra bandwidth.

The one factor that can really made a difference is the accuracy of the sample rate. Most digimode software uses either 11025Hz or 48000Hz. There is no theoretical advantage to using a faster than 11025Hz rate for terrestrial digimodes. A 48kHz sample rate should not give any benefit and will need more CPU cycles to transfer and process the extra samples.

Sample rate accuracy is important because it affects both the pitch of playback and the data rate. It's like playing an LP at the wrong speed. If you play a 33rpm LP at 45rpm the music is played at a higher pitch and a faster tempo. If played at a lower speed the sound is lower pitched and slower. This is analogous to what happens if the sample rate of your sound card is not exactly what your digimode software expects it to be.

I tested a number of sound devices using CheckSR.exe. This is a utility that is distributed with the MixW digimode software, but you can probably find it on its own if you Google it. To use it you simply select sound devices for input and output and set the sample rate you wish to test. You then run it until the measured sample rate settles on a stable figure.

I tested the Realtek sound cards built into my shack PC (HP) and a laptop (Dell) using both 11025Hz and 48000Hz sample rates. Both sound cards were as close to the specified sample rate as makes no difference.

CheckSR result at 11025Hz with USB device
I then tested a number of USB devices ranging from a $1 audio 'dongle' to a $10 model with surround sound and SP-DIF inputs and outputs. The drivers for these devices had names like 'USB sound device', 'Generic USB sound device' and  'USB headphone set'. These devices were also close to spot-on at 48000Hz.

But at 11025Hz every single USB device had a measured sample rate of 11100Hz - 1% faster than specified. This would make a 1kHz audio tone play at 1010Hz, whilst a 1200baud APRS packet would be transmitted at a rate of 1212baud. This error is more than enough to prevent decoding of an FSK packet signal. Other digimodes are also subject to sample rate errors. If you have ever seen a PSK or Olivia  signal that is strong and clear yet decodes as garbage, an incorrect sample rate (at one end or the other) is the reason.

I was surprised that the sample rate error at 11025Hz was consistent across all USB device samples. This suggests to me that the measured rate of 11100Hz is a factor of the drivers for these devices which may not run at the speed you select but instead resample down from a native speed of 48kHz. It would be interesting to see the results of running CheckSR on some branded USB devices or SignaLink USB interfaces that have their own drivers.

I ran some tests on USB devices at other sample rates. There was no consistency. At 8000Hz the measured rate was fast by a significant amount, but 16000Hz it was slower.

The results suggest that USB audio devices are only as good as internal sound cards if a 48000Hz sample rate is used. The use of lower sample rates with USB devices should be avoided.

3 comments:

Tim said...

Very interesting Julian - I am going to look at my soundcards now!

Unknown said...

Seems to be a Windows XP bug, and not surprising, its handling of audio is pretty atrocious: http://www.tigertronics.com/slusbts.htm#11025%20Hz%20Sample%20Rate%20offset%20error

Time to upgrade?

I suspect it's in the USB Audio Class driver when using adaptive clocking, which bases the audio clock on the rate at which the PC sends data to the USB device. USB devices that have their own drivers usually use a different clocking strategy that doesn't depend on the PC.

Unknown said...

Thanks for that link. I am using Windows XP. So it seems the issue is already known about.