• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Tests of Fade-In Behavior of USB DACs and DAC/HP Amp Devices

jkim

Senior Member
Forum Donor
Joined
May 23, 2024
Messages
384
Likes
799
Location
US
In many review threads, ASR members have reported and discussed all kinds of quirks concerning USB DACs and DAC/HP amp combo devices that can limit those devices' usability. One serious issue is the behavior we call a fade-in or "ramp-up" effect which occurs when playback starts after a device idles for a short time entering its power-saving mode. In this situation, when audio is played the device skips the first second or less of the content. This behavior was reported, for example, in the Fosi Audio DS 2 thread by multiple users.

We must admit that there should be multiple factors in this phenomenon, like the host device, its operating system & settings, playback software, etc. Nonetheless, the information of affected devices and how they are affected should be valuable to potential buyers. Although it is tricky to come up with a testing method, we may still want to have some starting point.

Suggested below is a testing methodology that characterizes these devices' fade-in behavior. Although the testing method is currently only for Windows 11 and foobar2000, with contribution from ASR members the methodology can be expanded and refined.

For the testing environment on Windows 11, the recommendations below, excerpted from this study, were followed:
  • Install Equalizer APO and use it to disable original APOs and set EAPO's preamp gain at ~ -4 dB to avoid upsample overs, filtering induced peaks, and the Windows CAudioLimiter.
  • Set Windows audio to 24 bits (or 32 bits if supported) so that its added dither doesn't compromise dynamic range.
  • Set Windows sample rate to the same rate as the native file, or to 96 kHz if you play back high resolution material.
  • Turn off Windows system sounds and enhancements.
The testing method involves the following three conditions:
  1. 10 or more seconds of idling after Windows volume change prompt is heard (volume changed after foobar2000 stopped ⏹️);
  2. Shortly after playback is stopped ⏹️ in foobar2000;
  3. 10 or more seconds after playback is paused ⏸️ in foobar2000.
In each of these three conditions, use and listen to two kinds of testing audio material:
  • "Test" chimes in Windows Sound Settings 2025-05-23 09_28_22-Settings.png
  • A song track in foobar2000 (see below to select a suitable song track)
And observe whether the first second or less of audio is skipped or not.

For the song track to be played in foobar2000 (or any other software) for testing, a song that begins right away with no silence is appropriate. And though not critical, it is interesting to note that the short "Test" chimes in Windows Sound Settings do not cause a device to exit from its power-saving mode in most cases.

With this method, all the USB DAC/HP amps I have in hand were tested. Here are the results:

2025-05-22-Tests of Muting Behavior of DAC_Headphone Amplifiers B.png


Note that the FIIO KA15 skips in every test. It is advertised as having very low power consumption. The test results may be attributed to its aggressive power saving scheme. And some do not skip in any test. These include the E1DA 9039S and Qudelix 5K, the designers of which we know are meticulous engineers who pay attention to details.

Here's a link to the spreadsheet "Tests of Fade-In Behavior of DAC/Headphone Amplifiers", which will be updated as more information is collected from ASR members.

Lastly, PLEASE contribute to this compilation of tests by posting results to this thread. The testing environment can be of any kind, depending on which you may want to modify the testing method. I could reorganize the test results as we move on accordingly. And any other suggestions would be considered, too.
 
Last edited:
Reserved as a placeholder.
 
What does Muted vs non-Muted mean? Do you mean delayed/skipped playback in the table?
Not delayed but skipped, as described in the post:
Observe whether the first second or (a bit) less of audio (test audio material) is muted or not.

EDIT. The terms have been changed to "Skip" vs. "No Skip."
 
Last edited:
Any correlation with power consumption? If the “skips” actually save power, then it may be an acceptable trade-off (?), but if it does not significantly reduce the power consumption, then it’s just poor engineering…
 
Any correlation with power consumption? If the “skips” actually save power, then it may be an acceptable trade-off (?), but if it does not significantly reduce the power consumption, then it’s just poor engineering…
This is a good point, and most likely what actually happens.
 
Last edited:
If the “skips” actually save power
We buy a product for a specific function, not for "saving" power by being essentially defective. And if I do not want some device to consume power when I'm not using it, I just unplug it.
 
Reckon power consumption is an important consideration, particularly when we are talking about battery powered devices. Personally I can live with the fading in/out if it's necessary to avoid pops and saves battery. Don't use it in my primary playback system however.
Not ideal, but where the Fosi Audio DS2 is concerned, a worthwhile price to pay for such awesome sound quality performance, I reckon. As ever : YMMV.
 
Think that I read somewhere that it is also to avoid unwanted clicks/pops between tracks when using one of the Cirrus Logic DAC chips. Think it was relating to the Fosi Audio DS2.
Edit, Link here : Post in thread 'Fosi Audio DS2 Portable DAC & Amp Review' https://audiosciencereview.com/foru...s2-portable-dac-amp-review.57063/post-2310153
This could be another justification. But again, these pops & clicks are most likely very short so, if they mute the DAC for seconds (very noticeable) instead of what should be ms, this again points to poor engineering and lack of care about the user IMO...
 
Think that I read somewhere that it is also to avoid unwanted clicks/pops between tracks when using one of the Cirrus Logic DAC chips. Think it was relating to the Fosi Audio DS2.
Edit, Link here : Post in thread 'Fosi Audio DS2 Portable DAC & Amp Review' https://audiosciencereview.com/foru...s2-portable-dac-amp-review.57063/post-2310153
Now I remember reading that post. Interestingly the JCally JM20 and JM20 Max (w/ CS43131) that I tested do not have this fade-in or skipping problem while producing no clicks or pops. However, multiple users report their JM20s produce brief pink noise when playback starts (@fws here; @mc.god here; @kekus here). And @multiformous reports his JM20 Max has a fade-in effect. Very puzzling.

If Fosi Audio's statement is truly correct, implying that these pops are unavoidable, in certain conditions, without implementing fade-in or skipping for all CS431xx-based devices, then it is another serious problem of these DAC chips. Of course, it is too early to conclude.
 
Last edited:
after Windows volume change prompt is heard
I've seen this "volume change prompt" mentioned a few times. What is it exactly? I sporadically use Windows but I don't think I noticed such a thing.
 
So I was just testing the JM20 Max on a few other devices. On my Windows 10 PC, playing the sound device 'test' chimes results in an obvious fade in for the sounds in both channels. In various players I've tried (foobar, musicbee mediamonkey), the audio clearly fades in when starting from 'stopped' to pressing play. But if I start playing in foobar and get the fade in, then double-click the track to start playing from the beginning again, there is no fade in. Hitting stop, then starting gets me the fade.

I tried the JM20 Max on a Windows 11 laptop, and got the same fade in behaviour.

On my Android device, it's a similar story. With the JM20 Max in exclusive mode in UAPP, I get the fade in any time I start playing audio -- regardless if starting from stopped or while something is already playing. But if I use UAPP without using exclusive mode, I get the fade in from stopped condition but if I restart the track while something is playing, it plays the start correctly without a fade. With the Hiby player in exclusive mode, it fades in from stopped position but restarting while playing doesn't fade in.

This is pretty annoying... and yes, as mentioned in another thread, I quickly tested the other dongles I have on hand with the Windows test chimes and got these results :

Apple dongle: fade in
Jcally JM12 (JA11 firmware) [KT02H20]: start of audio is truncated
Jcally JM12 (TinHifi firmware) [KT02H20]: audio starts normally
Jcally JM6, VE Abigail [CX31993]: audio starts normally
JCally JM20 Max: fade in
Meizu HiFi (non-pro) [CS43131]: fade in
Samsung: audio starts normally
 
Last edited:
Curious if this can be narrowed down to a particular DAC chip or whatever.
Is it just the CS43131?
 
So I was just testing the JM20 Max on a few other devices. On my Windows 10 PC, playing the sound device 'test' chimes results in an obvious fade in for the sounds in both channels. In various players I've tried (foobar, musicbee mediamonkey), the audio clearly fades in when starting from 'stopped' to pressing play. But if I start playing in foobar and get the fade in, then double-click the track to start playing from the beginning again, there is no fade in. Hitting stop, then starting gets me the fade.

I tried the JM20 Max on a Windows 11 laptop, and got the same fade in behaviour.

On my Android device, it's a similar story. With the JM20 Max in exclusive mode in UAPP, I get the fade in any time I start playing audio -- regardless if starting from stopped or while something is already playing. But if I use UAPP without using exclusive mode, I get the fade in from stopped condition but if I restart the track while something is playing, it plays the start correctly without a fade. With the Hiby player in exclusive mode, it fades in from stopped position but restarting while playing doesn't fade in.

This is pretty annoying... and yes, as mentioned in another thread, I quickly tested the other dongles I have on hand with the Windows test chimes and got these results :

Apple dongle: fade in
Jcally JM12 (JA11 firmware) [KT02H20]: start of audio is truncated
Jcally JM12 (TinHifi firmware) [KT02H20]: audio starts normally
Jcally JM6, VE Abigail [CX31993]: audio starts normally
JCally JM20 Max: fade in
Meizu HiFi (non-pro) [CS43131]: fade in
Samsung: audio starts normally
Thanks for making this post here. If you can put a bit extra effort, would you test these dongles according to my suggested test method (i.e., three conditions and two kinds of test material)? Then I will be able to update the spreadsheet with full information.
 
I've seen this "volume change prompt" mentioned a few times. What is it exactly? I sporadically use Windows but I don't think I noticed such a thing.
Simply move the volume slider either on the task bar's pop-up window or on the Sound Settings. You will hear a chime prompting the volume change.
 
Curious if this can be narrowed down to a particular DAC chip or whatever.
Is it just the CS43131?
We do not know. But I believe this behavior can be programmed on a USB bridge chip.
 
We do not know. But I believe this behavior can be programmed on a USB bridge chip.
I know, right?
I wish if Savitech will come out with a fix firmware (for USB bridge chips such as SL9123L).
 
So after fiddling with the JM20 Max a bit today, I've found some ways to mitigate the fade in issue when starting playback in various players.

Using MusicBee on Windows 10 in WASAPI exclusive mode, I enabled "Play some silence at startup for hardware synchronization" under the Player options in the Preferences. After a slight delay, music starts normally with no fade in / ramp up or crackles or hiccups, etc.

On Android with UAPP, I dug around the settings for a similar option and found "DAC Warm-Up Time" in the settings under "USB Audio Tweaks". Adding ~500ms of delay seems to cover it, resulting in a clean start to playback with no fade in.

I also use MediaMonkey on Windows, but haven't found a similar setting to delay the start of playback to avoid the fade in. But selecting 'DirectSound' as the output and starting playback, I get the fade in -- but if I stop the playback and start again, the music plays normally as though the dongle 'stays awake' and doesn't need to ramp up again. The 'cold start' gets me the fade in, but for some reason using MediaMonkey in this way keeps the dongle active so if I stop and start playback or try something like the Windows test chime or playing in foobar I don't get the ramp up.

Kind of annoying behaviour, and to be honest if I'd seen anyone else mention this quirk earlier I probably wouldn't have the purchased the JM20 Max. But after figuring it out this much, I'll go on using it.
 
Intrigued by this post I wanted to double check on my JM20, and i can confirm it.
My tests are in Linux -> audio properties panel -> hardware -> select the device you want to test -> speakers test, clicking the 2 buttons you hear respectively "front left" and "front right"

Jcally JM20 (CS43131 - Savitech bridge - ASYNC usb)
high gain

no ramp-up\fade-in effect, you hear the entire phrase but with short pink noise in background for the first half second played when the device is idle (not playing) for at least 5 seconds.
low gain
no issue, you hear the entire phrase with clean background, no matters how much time you leave it idle

Then I wanted to re-check my other dongles, changing gain when it is possible:

Tempotec sonata BHD (dual CS43131 - Savitech bridge - ASYNC usb)
low gain - mid gain

ramp-up issue: clicking on "front left" you can only hear "left", then after 5 second clicking on "front right" you can hear "t right", so right channel come up a fraction earlier than left one (panning effect), both truncating the very first samples.
high gain
no issue, you can always hear the entire "front" word on both channels, no matters how much time you leave it idle

Kuang Pai Player 3 (dual CS43131 - Savitech bridge - ASYNC usb)
low gain - high gain

ramp-up issue: clicking on "front left" you can only hear "ont left", then after 5 second clicking on "front right" you can hear "ront right", so right channel come up a fraction earlier than left one (panning effect), both truncating the very first samples.
So it's a bit faster than Sonata (truncate less samples) but has the issue in any mode you use it

Ugreen HiFi Audio Pro (CS43131 - CS46L41 bridge - SYNC usb)
low gain - high gain

no issue, you can always hear the entire "front" word on both channels, no matters how much time you leave it idle

CX-Pro (Grave Audio DA06 CX31993 - TTGK bridge - SYNC usb)
only 1V mode

no issue, you can always hear the entire "front" word on both channels, no matters how much time you leave it idle

Hi-Max (CB1200AU chipset - ADAPTIVE usb)
only 1V mode

no issue, you can always hear the entire "front" word on both channels, no matters how much time you leave it idle

So, different behaviors, some devices are always ok, others change with gain mode, others are always affected. In my case the only common factors between the device that are affected by some extent is the Savitech bridge and the corresponding ASYNC usb transfer.
Maybe the JM20 pink noise is one of the artifacts that Fosi Audio referred to saying that the ramp-up was a necessary setting to avoid them, but it happens only in high gain, while Sonata is perfect in high gain and has the ramp-up in lower gain modes, so high variability and nothing can be concluded with confidence.

Did not run tests in other applications, since it is proven that depending on the application and how it keeps the device asleep the issue will not appear even if the device is affected, for example if i leave an audio editor like Ocenaudio with the dongle as output card, it is kept always asleep even if nothing playing.
From my point of view, if the issue appears in the OS speaker test, a device is to be considered affected.

Since my tests are under Linux they are not compliant to @jkim method, so I'm not going to update the spreadsheet and will leave the choice to him.
 
Last edited:
Back
Top Bottom