System Administration, Reconfigurable Computing and Other Random Topics

Understanding USB Microphone Whine

I recently got my hands on a USB microphone, namely the Samson Meteor Mic, a large diaphragm electret condenser microphone that not only looks cute but also has overall good reviews online. However, when testing the microphone I was rather disappointed by the annoying background noise that is clearly audible when turning up the volume of the microphone. Have a listen:

Example of background noise
Same example as before but amplified

We hear two things here: One is relatively normal microphone hiss. The other is a high-pitched noise which you really do not want to have in your recordings. Let’s have a look at the spectrum of the recorded noise, using Audacity and its spectrum analysis (i.e., an FFT):

FFT of recorded noise (please excuse the bad contrast)

We can clearly see a peak at exactly 1 kHz as well as corresponding harmonics. Interestingly, these harmonics seem to disappear at 7, 8 and 9 kHz and reappear at 10 kHz. We will come to this later.

First aid: Filtering out the noise

For Windows and older versions of macOS, Samson provides an additional software called Sound Deck that among other features provides live noise filtering. This in fact seems to remedy the issue. However, for Linux users this is of no use and also I wanted to understand where the noise is coming from.

Looking around online, it turned out to be a widespread issue, not only with this but with different USB microphones. In particular the Audacity forum has a couple of threads on the topic. Here is just a small selection:

In the Audacity community, the phenomenon is commonly called USB Whine, Frying Mosquitoes or the Yeti Curse, named after the popular USB microphone Blue Yeti. Especially interesting is that last thread where a filter plugin is shared that is able to remove the annoying sound without damaging the audio too much. It places notch filters at the corresponding frequencies. Let’s have a look at how this works.

The following shows the spectrogram view of the recorded noise from above (not amplified):

Spectrogram of recorded noise

The whining sound clearly stands out. Now let’s apply the filter in its most recent version, named Mosquito-Killer4. When running the filter, one can specify how many of the frequencies should be removed (default: 8). Here is how the result looks like:

Spectrogram after applying the MosquitoKiller4.

One can faintly see the white lines where the filter removed the noise. Apart from that, this now looks like a relatively clean background for a recording. Here is how that sounds:

Noise recording after applying the MosquitoKiller4 (amplified)

Better: Avoiding the noise in the first place

While the filter shown above is powerful in removing the noise in recorded audio, it still may remove sound at those frequencies that has been deliberately recorded. Also, it is not applicable in a live audio situation, like a video conference. [Update: See addendum below for a live filtering solution] A better solution would therefore be to get rid of the noise before it ends up in the recording.

Reading through the forum posts, it becomes clear that the USB whine does not come from the microphone itself, but rather some electromagnetic interference (EMI) picked up through the cable. I got myself a couple of cables and tested how they influence the noise:

Cable 1: Rather long and flexible. Likely the cable provided with the microphone.
Cable 1 Spectrogram. Whining noise clearly visible and audible.
Cable 2: Very short, stiffer than cable 1.
Cable 2: Spectrogram. Noise barely visible or audible.
Cable 3: Y-type cable coming from an external USB hard drive. Connected only via the main plug (not the AUX power). The cable is not only short but also very thick.
Cable 3: Spectrogram. So far the cleanest background signal. No indication of USB whine.
Cable 4: Another long cable but being less flexible it appears to be more solid than cable 1.
Cable 4: Spectrogram. This seems to be the noisiest of them all and in fact this recording is what I used so far in this article to demonstrate the whining sound.

Overall, using short cables seems to be a good way to avoid the whining sound in the first place. As cable 3 provided the cleanest output, here is the corresponding recording:

Clean recording using cable 3. Not amplified, so this can be compared to the very first audio file in this article.

Finding the root cause of the whine

The big remaining question is: Where does the noise come from? We already got a couple of clues:

  • The noise is picked up by the USB cable. So it does not come from the 5V USB supply rail of the host or the microphone itself.
  • The noise is always at 1 kHz and multiples of that frequency. That makes it unlikely that the noise originates from external devices (LED lighting, monitors, wireless devices, etc.).
  • The FFT shows the intensity of the harmonics decreasing for higher frequencies, basically vanishing at 8 and 9 kHz and returning afterwards at 10 kHz. This suggests a somewhat periodic amplitude of the harmonics and therefore a signal that corresponds to a pulse of certain length, repeating each millisecond (1 kHz base frequency). See figure 13-10 of The Scientist and Engineer’s Guide to Digital Signal Processing by Steven W. Smith.

All of this suggests that the noise actually comes from the USB data lines within the cable itself. USB communication is always initiated by the host and never by the device. Therefore the host regularly polls the device to ask whether it wants to transmit any data to the host. A typical frequency for this polling is 1 kHz. Once every millisecond, there will be communication between the host and the microphone, somehow affecting the recording. The fact that the length of the cable plays an important role suggests that there is cross-talk between the data and power lines within the cable.

To be able to look at the USB power line with an oscilloscope, I sacrificed cable 4:

Modification (controlled destruction) of cable 4 to allow measurements.

The cable seems to be properly built, providing double shielding (metallic foil + braided mesh) and the data lines (green and white) are in a twisted-pair configuration. All of the following measurements are done with reference to the shield instead of the black ground wire. Absolute voltages may therefore slightly differ from voltages seen by the microphone’s circuit.

Looking at the waveform (AC coupled) immediately reveals the source of the noise:

USB polling with 1 kHz frequency
One of these pulses: The exact length varies, but on my system the data exchange takes up to 140µs.

Out of curiosity, I tried to manually draw a waveform in Audacity that consist of 140µs pulses in a 1ms interval. Here is how that sounds:

Synthetic noise: Pulses of 140µs length in a 1ms interval. WARNING: This sound is rather unpleasent. Only play at low volume.

Finally, let’s look at the FFT of that synthetic noise:

FFT of synthetic noise (please excuse the bad contrast)

Now, doesn’t that sound and look familiar?

Final remarks

  • While this was a fun investigation and there are means to control the noise (using a short cable, filtering in post), I wish all USB microphones were built in a way that makes them unsusceptible to this problem. I had the chance to test a Røde VideoMic NTG and it did not suffer from this problem. Granted, that microphone costs a lot more, but I cannot imagine that additional filtering on the 5V rail would increase the cost of USB microphones that much.
  • There is a video series on microphone and amplifier design on the EEVblog with one section that may explain how the noise from the power rail ends up in the microphone output.
  • The quality of the USB cable might play an important role as well. In theory, the twisted-pair configuration of the data lines should massively reduce any interference caused by differential signals on those lines. Maybe some cables do this better than others.
  • There are devices available to buy that are supposed to clean up USB power rails, especially for use with analog audio devices (microphones, DACs, ADCs). However, even if these devices work perfectly, I would expect the noise to be reintroduced in the cabling between that power conditioner and the audio device. I have never tested one of these devices though so I cannot say whether they work as intended or not. Reports in the Audacity forums seem to be mixed.
  • In theory, also on Linux a real-time filtering should be possible via PulseAudio or PipeWire. However, I have not tested this. Also I am not aware of a real-time filter that focuses on this specific kind of noise.

Addendum (Sep 17, 2021): A real-time filtering solution

I published an open source LADSPA plugin on github that is able to perform a noise filtering very similar to above mentioned MosquitoKiller4 in real time. In fact, it can be configured to place notch filters at any base frequency and a specified number of harmonics. On Linux, PulseAudio or Pipewire can be used to create a virtual input that provides the filtered microphone input to applications. While I still think that avoiding the noise altogether by using good and short cabling is the best solution, there is now a real time filtering solution for Linux as well. Enjoy!

6 Responses to Understanding USB Microphone Whine

  1. Thanassis says:

    Absolutely excellent article – I learned tons. Thanks!

  2. John says:

    Hi. Just want to say excellent work with this and actually this tutorial and the Audacity plugin really made me realize what was wrong with my Blue Yeti about a year back.

    But after discovering this new trick, I thought I’d revisit this article and share it here.

    For real-time filtering, I suggest you check out Peter’s Equalizer. What I did was, I added the 1000, 2000, 3000 and 4000 frequencies to the equalizer and lowered it a bit and there was a great improvement. I’m not an audio engineer so perhaps you can play around with this tool because it’s super useful for real-time filtering.

    I learned of the app from here: https://www.youtube.com/watch?v=IgZJLydfqTc

    Then the apps required to make it happen are here.


    Thanks again!

    • Michael says:

      Hi. Thanks for posting! This looks like a good solution for real-time filtering on Windows. I guess you can play with the Quality (Q) values to make the notches quite narrow. With that setup it should roughly match the custom filters available for Audacity and LADSPA.

  3. Robin says:

    Thank you so much for the article, i finally understand what is happening instead of just getting “band aid” solution recommandations like using nvidia broadcast and whatnot ! I’ll try using a shorter and better câble and see how it goes :) !

  4. Ken Dickson says:

    Wonderful article that surely solved my problem. I was looking to buy the Samson Meteor Mic. However, I stumbled on an Anker powercast M300 USB Microphone first. It was slightly used for only $25. It had great reviews on YouTube but I was really disappointed with the USB Whine when I tested recording in Audacity on Linux. The Mosquito-Killer plug in for Audacity is a simple solution and works great for what I do. Thank you for sharing!

  5. MicWHINE says:

    This is such an amazing and informative post. I very much appreciate your investigative approach and the testing of different cables to accurately determine the issue. The representation of the sound on the spectrum was also very informative for comparison.

    Fortunately, I also managed to fix the whining noise on my usb microphone which sounded identical to yours. Simply using another cable fixed my microphone whine. This is strange as it didn’t seem to have any protection against interference as it was a bog standard USB type B printer cable. Whereas the one that came with my microphone had a little bulb at the end which should help with intereference yet produced the most whine.

    It makes me question how many people deal with this noise thinking its the microphone when the real culprit is the cable. I know I have blamed several microphones when the problem really could have been with the cables. Thanks again!

Leave a Reply

Your email address will not be published. Required fields are marked *

Captcha loading...