Spikey wrote:Thanks sergm, I will try it. With the WDM-KS I was almost synced to my external synth, there was a fraction of a second delay only. Enough for the drums to sound out of sync slightly, but only only just.
Come on, this is a huge delay (in terms of audio latency). Unfortunately, it is quite complicated to estimate the total delay you get between issuing a NoteOn and actual hearing the note attack. This is very system-dependent. The total delay include not only buffering in the synth application but also delays added during DSP in the audio drivers or any transient libraries (on which we may have little influence if not at all). Besides, there are always delays in the actual analog audio path (though, usually they are negligible compared to the DSP delays). All these things are out of scope here. What we can manage is the buffering in the synth application.
Although note, even having 3 ms delay in the synth application does not guarantee that you hear sound of a note right after 3 ms since submitting the NoteOn. For example, on a Linux system when using PulseAudio library for audio output, we may configure tiny buffer in the synth but the PulseAudio library nevertheless adds enormous delay by itself. So, in this case the first thing we usually do is bypassing the damn PulseAudio library... What I mean here is finding the minimum possible latency for your system requires some careful analysis.
BTW: How did you arrive at those latency numbers? I would love to be able to analyze like that, it would make this a lot easier.
These figures are dumped from the synth application console. They only reflect the configuration I set in the audio properties dialog, nothing more. Generally, you try setting various figures there and find out which are enough by ear 😉 I mean when you set the buffer size too small, you'll get buffer underflows which sound like cracklings in the audio (or no audio at all). Some audio API may provide additional warnings about buffer underflows, and they are logged in the synth console. But since not all audio APIs do this, we don't show warnings e.g. in the system tray about that (for consistency). Just one thing in which that console output is helpful - you can realize whether your tried settings really take effect. Among other things, not all audio APIs allow arbitrary settings, most adjust them on their own, e.g. no matter which latency I set with PortAudio/WASAPI, I get minimum 22 ms of latency (in the non-exclusive mode). So, at least PortAudio/WASAPI is fair and report to me about additional delay, in contrast to the PulseAudio on Linux... If you want to see the debug console, you attach a debugger (e.g. Visual Studio's) to the process mt32emu-qt and see the output. If you find this way awkward, I can provide a binary which opens the debug console in another window, like it was in earlier versions (as a short-time solution). Just point out whether you want it with float samples - still in progress to get rid of these compiler options.