Latest debug attached.
I made 2 attempts at VT. At 10:25:40 I pressed record.
Player A started, I was able to record some voice, but noticed the mic waveform frozen, but the mic time counter was running. I was able to start player B. Stopped the process and cancelled VT recording.
made a second attempt: mic pressed at 10:28:30 Mic channel frozen again.
There is no mic monitor signal.
I will repeat with a mic monitor signal.
debug-20141119-10.txt (611 Bytes)
I’ve set mic monitor to direct sound u56. There is a delay of about 100ms after speaking I noticed when listening.
10:42:00 record. Player A frozen…infact a right mess.
10:44:00 tried again Player A frozen and B…I’m losing the plot.
debug-20141119-10.txt (28 KB)
Can you give me remote access to your machine so I can try a few things? Send the connection details by email please, tw@mairlist.com.
Turned out that the entire Windows system was frozen for a few seconds during recording. When all DirectSound devices where set to floating point, it appeared to happen less frequently.
I still don’t know why v4.4 behaved differently - maybe a matter of the settings, I didn’t compare them one by one.
Regarding the 100ms you noticed in the debug build:
When recording and playing at the same time, there will always be a small delay/latency, because the recorded data must be buffered for playback. The minimum latency is actually determined by the buffer size of the playback device.
mAirList has an algorithm (the one I mentioned above) that tries to sync the devices to the lowest possible latency during the first second or so. I found that the mechanism doesn’t always work, so I will introduce an option to specify the desired latency in the future.
Thanks for all your time and efforts. Much appreciated.