Popping on beginning and end of track while using USB DAC (with workaround)

Recently I've designed an USB DAC with integrated headphone amplifier, based around PCM5102A-Q1. It is a Class 1 device, so it's plug-and-play, immidiately working with USB driver in Windows. The problem is: whenever sound starts or stops, a fart/pop can be heard. It doesn't happen during the sound, it happens only at the beginning and end of it. Its volume is not changed with system volume or Youtube volume. Volume of the fart is higher when a sound starts than when it stops. It's low volume, but enough to be annoying when listening at normal level.

This problem is known in the Internet, but most threads with similar complaints are resolved by changing stuff in the Realtek driver, which is not my case, as Realtek handles only front and back 3,5 mm jacks. USB audio is handled by generic Windows driver. Other threads end with no solution. There is also one thread on TI forum complaining about pops caused by auto-mute circuitry inside PCM5102, but reading through it I am sure this is also not my case.

I've tried updating the driver, but my Windows 7 says it is up to date.
I've tried it on different computer with Windows 10, the farting was present also there.
I've tried playing a "10 seconds of silence" from Youtube and the fart could be heard when it starts. 10 seconds of silence - YouTube
I've tried all combinations of bitrate and sampling frequencies.
I've tried enabling and disabling full control over the device by applications.
I've turned off all sound enhancements.
The fart sounding pop was still happening.

I've hooked up the device to an oscilloscope and started looking at the USB and I2S signals. When no music is played, there is very little information going on, a small packet of like a dozen bits every milisecond, but I2S data line is always at 0 V level. When 10 seconds of silence is playing, there is lots of USB data going on, but I2S data line is as silent as it was when nothing was playing. When the fart happens during the start of 10 seconds of silence, the I2S is still constantly sending 0 V! Meaning that my USB-I2S bridge properly identifies zero data and tells the DAC to keep silent, but the fart is still happening...
Note: YouTube keeps pushing data over USB for 11-13 seconds after the video is paused/ends. Similarly, Windows Media Player does the same for about 1 second. If I unpause Youtube video during that time, it doesn't produce a pop. If I unpause Windows Media player at any time, it doesn't produce a pop, but it does produce it the first time I open a file with it.

So I've started looking at what happens with power. On the oscilloscope I can see that there is a drop of about 70 mV in the 5 V line coming from the PC. It propagates a bit through my system in a way I don't completely understand: I can't see it in neither 3,3 V supplying digital side of the DAC and USB-I2S bridge nor analog 3,3 V (from separate regulator) for DAC, but I can see it on the -3,3 V which the DAC generates itself. That's when I decided to check more on the PC side...

As there is properly no data being produced on I2S line when nothing is playing, I've decided to make a short .wav file containing exact silence. When it is opened - even paused! - in Windows Media Player, the farting pop is gone. I imagine (not know) that Windows Media Player keeps the music prepared for unpausing, and thus preventing the driver from turning off.
To me it is obvious that the problem is on PC side and has to do with how audio is handled by USB driver from Windows. What is not obvious to me: how to force USB driver to work poplessly without the workaround?


Short summary of the project:
- USB audio class 1 device for plug-and-play operation, powered from USB
- STM32F446 as USB-I2S bridge, project taken from USB I2S преобразователь 32bit/96kHz, SUPER PRIME chipdip, USB Hi-Res Audio, квадро, STM32F446RC, Электронные войска | купить в розницу и оптом (open source, license allows for modifying even for commercial products)
- PCM5102A-Q1 DAC
- INA1620 amplifier
- power converter generating +/-8 V for output stage
The result is a DAC capable of playing up to 24-bit 96 kHz, with very good sound quality and power amplifier outputting 4 V RMS at the output, albeit limited by 22 R - still enough to produce headphone shaking bass and headaches. Just what I needed.
 

Attachments

  • usb-dac.jpg
    usb-dac.jpg
    986.6 KB · Views: 126
Last edited:
In my experience, the pops/farts are usually caused by clock changes. Have you checked you SCK during the pops?
Drivers usually control clock changes and some revert back to 44.1 by default on stop. So if you're playing 44.1 content you might not hear the pops, but anything else would cause them.
 
I have nothing to add here, but am interested in seeing your solution if you can find one.

I am using a cheap SD card player from aliexpress. Sound quality in general is excellent, but it reacts badly with some types of metadata in the file (white noise at the end of the track) and also I notice that one some SD cards there is a click when you first press play, and on some cards it is louder than others.

fran
 
In my experience, the pops/farts are usually caused by clock changes. Have you checked you SCK during the pops?
Drivers usually control clock changes and some revert back to 44.1 by default on stop. So if you're playing 44.1 content you might not hear the pops, but anything else would cause them.

From what I've seen with the scope, all the clocks are present and stable all the time, LRCK being solid 96 kHz. I can't see any changes or pauses in it. My scope doesn't have the memory to record a second or so with enough sample rate to determine clock freuqency changes.
But when I accidentaly shorted the LRCK line to ground (with oscilloscope tip) and then unshorted it, I've heard the same pop sound! So maybe the clock is paused for a short moment, but I can't see it with my scope?


In the meantime I've tested the problem on Linux. It doesn't happen with Linux driver.
 
Modern USB boards and chips usually can provide a MUTE output that can be used to mute the dac output when a glitch might occur. That would normally be one of the things to try.

OTOH, if its a driver problem it could be a buffer in the PC is not getting cleared before being used again. Something like that. Sometimes a different OS won't have the same problem.
 
Last edited:
In the meantime I've tested the problem on Linux. It doesn't happen with Linux driver.

On Linux, some software keep playing silence to keep the devices running. Best way to make sure it's not a clock issue is to play two tracks with different sample rates one after another. If there is no pop in between, then it's probably not a clock issue.