WASAPI: Undesirable Fade-in effect at timestamp 0,0000

Some time ago I changed the audio host from MME to WASAPI, for some reason. From that time I can hear an effect, which I want to discuss:

I always use a rhythm track for recording music. In touch with the WASAPI host, the metronome click at timestamp 0,0000 has a different sound in comparison to the other clicks. This was just an observation and didn’t disturb my music work in detail. But as a technician I studied this effect in depth. And I’m not sure, is this effect…

  • … just with my German hardware environment?
  • … do other folks have the same watching?
  • … a feature of WASAPI?
  • … a feature of Audacity?
  • … a “feature” which should be eliminated?

And as said in my introduction: only audible with host WASAPI and not with MME or DirectSound.

The setup for hearing this effect is very easy to do:

Generate / Tone … 4 kHz with a length of 4 ms(!). With an according zoom in you get the following picture:

Press play: the sound is like an airless hushed chirp, if at all.

Now move the clip just some samples (> 5) away from position 0,0000:

Press play again (cursor at position 0,0000) and the sound is a crispy chirp as I would expect.

Now follows some side effects evaluated by my tests:

Position the cursor anywhere within the clip:

Result: an airless hushed chirp

Then I want to record this effect with the overdubbing method into a new track. Result: the effect is gone. You always hear (and record) a crispy chirp.

Next experiment:

I divide the clip according the picture and start at the shown cursor position:

Result: an airless hushed chirp

And last test: position the start point in the gap between the clips:

Result: a crispy chirp

Finally I recorded this effect with an external recorder and manually adjusted recording level. The result I imported into Audacity and aligned the recordings at the right side of the master “Tone” which is 15 ms in length (yellow cursor):

Tone track = Master signal
crispy track = recording of Tone as expected
airless track = airless hushed chirp recording

The selection at track airless shows the discussed effect which looks like a fade-in of 10 ms.


I can’t seem to be able to reproduce this testing on W10 using WASAPI as my host.

I generate a default click track. When I play it the original click at T=0 sounds exactly like the loud click that is 4 clicks along and the next 4 etc.

Zooming in I can see that the initial click is just like the loud clicks that occur every four clicks:

And here are the first four big clicks (with the intervening small clicks deleted) - all four look and sound the same to me:

My suspicion is that it is possibly your soundcard or your Windows audio settings (turn all “enhancements” off).

I have similar when I start to record from the onboard mic, it takes Windows a small but appreciable time to get up to full volume.


If not due to Windows playback enhancement,
check “Micro-Fades” are disabled in Audacity preferences …

And then maybe try a different audio host …

ok. Now I’m able to go closer to the problem :crazy_face:

Peter’s comment just says: it’s not reproducible. The suggestion “soundcard: turn all enhancements off” does not influence the behavior

Trebor’s comment: there is a feature in Audacity, wich I never had in focus - microfades

All details written in Trebor’s GitHub link I can confirm with my investigation.

Trebor’s suggestion to use the MME or DirectSound host, I will not follow because I have set a very long buffer length. With that buffer length MME and DirectSound is ugly to handle due to very long delays. And the long buffer length is necessary to eliminate one type of dropouts. But dropouts is another topic which I am still watching and collect surrounding details.

Nonetheless for completion I let follow my microfade investigations, which sounds very similar to the GitHub link content:

The microfades described in the manual (Playback Preferences - Audacity Manual ) were not set in my preferences. But after active setting the microfades I can hear exactly the same audio behavior which I described above in January. Excessively so the microfades are available through all hosts and during playback as well as overdub.

With this knowledge I’ve reset the microfades option and came to the following conclusion:

Before playback starts, Audacity looks to the first samples (maybe 5) of audio in front of the cursor. If there is a high enough jump in the amplitude, it starts playback with a microfade. In case of overdubbing this is ignored.

Here the reasons for my conclusion:

  • The automatic microfades are level sensitive
  • I can reproduce it very clearly with the 4 kHz sine tone (length 4-10 ms) as described above: If the generated amplitude is 1.0 and the Playback Level > 80% (round about), the playback is automatic microfaded. The amplitude can be influenced with either tone generator window amplitude, track volume slider or Audacity main volume slider
  • The behavior can NOT be influenced with the windows-inside audio slider
  • Another reproducing method is, if recorded tracks have a DC Offset: My “Terratec Aureon 7.1” produces a DC offset of -35 dB. After 2 recorded tracks the DC Offset is summarized to -29 dB and after 3 recorded tracks the DC Offset has a level of -25 dB. I can read this levels with the playback meter of Audacity. This DC offset of 3 DC afflicted tracks are enough to initiate the microfade playback. The picture below shows a +25 dB amplified recording.
  • In another method I use a standard rhythm click and manipulate the first half wave of the first click with the Draw Tool (F3) (see Audio 2 of the following picture). The green arrow shows, that especially the very first sample has big influence to this behavior.

Some questions and statement (seemed to be answered with the GitHub link content above).
• Why is this automatic microfade behavior only available with the WASAPI host?
• Why is there a difference with the automatic microfades between playback and recording (overdub)?
• With the knowledge of the preference setting “Options microfades”, the described behavior seems to be an undesirable muck effect.

So I’m looking forward seeing the GitHub entry resolved :smiley:
Thanks Peter and Trebor

Sadly, these questions are above my pay-grade …

I like your analysis though Henry.


1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.