I have updated the debug build, can you please try and send me the debug output? Also generate and send a bug report (from the About menu), so I can review your current audio settings.
https://www.dropbox.com/s/0n92rfajmvcq19s/setup.exe?dl=0
I found one issue where it can happen that a record device doesn’t deliver the data fast enough to keep in sync with the playback device. I was able to reproduce it by choosing the DirectSound microphone input (on my Parallels virtual machine, which is somewhat slow wrt. audio), and the WASAPI speakers output with a fairly low buffer setting (50ms). You could hear crackle, and see the “want: xxx, got: yyy” messages at the same time.
mAirList uses an adapting algorithm that tries to synchronize the record and playback devices with the lowest possible latency. When the recording is started, and there is not enough recorded data for playback, mAirList would insert null samples (that’s the crackle you hear) until the devices are eventually in sync.
That algorithm has already existed in v4.4, there haven’t been any changes to it.
The only change between v4.4 and v5.0 is that v5 is now using BASSmix splitters to distribute the recorded data to multiple “listeners” (monitor device; peakmeter; recorded WAV file), while v4.4 had my own code for that job (which I developed when BASSmix splitters didn’t exist).
What puzzles me a bit is that there is an effect on the playback devices you use for VT, although they aren’t connected to the record source in any way (record data goes to the “no playback” sink, not to any device).
And then I noticed something
10:26:59.121 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:26:59.121 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:26:59.136 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=3528
10:27:04.292 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:04.292 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552
10:27:04.308 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552
“HandleRecordData” means that the sound card is passing recorded sample data back to the application. You can see that there is an average of 10ms between two calls, and the data length is 1764 byte (which happens to be exactly 10ms worth of audio data with 44100/16bit/stereo).
Now in the above excerpt from the log file, there is suddenly a 5 second gap where no audio data is provided at all!
And here, again:
10:27:39.006 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:39.006 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:39.021 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:44.287 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=1764
10:27:44.287 (0) HandleRecordData: RecordChannel=B0000037, SplitChannel=B0000039, length=6552
In other words, the entire recording process stops for 5 seconds. Do you think this is the point where you clicked the record button?