I don't know if MUNT has support for ASIO, but you can try to install ASIO4all (http://www.asio4all.com/)
select it as an output and try it again.

Thanks, I'll try it tonight. Anyone else with ideas, let me know.

MUNT does not, but my sound card does, and I tried experimenting further with no success. Although, there's one or two more things I want to try.

Hey guys. Actually, munt has no special means to provide minimum latency, although I always keep this concern in mind. The minimum latency munt allows obviously depends on the system you use, so it's been made adjustable. It's easy to shrink the total latency (audio + MIDI) down to 35 ms on WinXP (with fast CPU) and it should work reliable below 20 ms on Windows 7+.

When it comes to further reducing latency on Windows, you should use PortAudio API available in the Qt app (Windows MIDI driver is limited to use WinMME only). It supports WASAPI directly but you need to recompile to use ASIO.

On other systems this turns to be completely different matter. OS X should allow to use 4 ms out of the box. On linuxes with pulseaudio 40 ms seems to be the lower limit. On the other hand, it's a piece of cake to get 8 ms with OSS4 or JACK which is also supported via PortAudio API.

sergm, thanks very much for the reply, I appreciate it.

I realized I had an old version installed, 1.3, so I upgraded to 1.5 and that helped a little bit too, plus more customization (your recommended value of 36 works well for audio latency, plus 1 and 1 for the others).

I messed around with the buffer size on my sound card, which slowed it a little to work better with MUNT. Still a little hang but almost nothing now.

How do you use PortAudio API (can you in the MUNT exe)? And has anyone compiled an ASIO version that you know of?

Great work on this program and thanks for all that you've done and still do.

Thank you for the kind words about the project. Sadly, we currently do much much less to advance it due to lack of time but I plan to put some efforts this summer (hopefully).

Well, I assume version 1.3 isn't so old in terms of audio latency (in contrast to e.g. 0.1.3, heh) but there is one thing to note. Overall latency of munt output depends on resampler of your audio system among other things. As you probably know, the current version of munt produces output at different sample rate by default. It may turn out that the output from munt 1.3 you used before was resampled from 32 kHz (internal MT32 sample rate) to the actual sample rate of your audio system (e.g. 48 kHz), and the resampler added additional delay (depending on implementation and may appear up to 10-20 ms).

Actually, the last version of mt32emu-qt app may produce audio signal at arbitrary sample rate, so you can adjust it if there is a need. The binaries at source forge use SOXR resample library, and it is known to introduce quite some latency due to using a FFT filter. While the latency added may appear negligible at higher sample rates, it turns to be a showstopper on lower sample rates. Recompiling with libsamplerate will help to address the latency issue but it'll also dramatically degrade performance. An attempt to solve both these problems is made in the internal resampler I recently added but it isn’t in production quality atm.

As for your question about PortAudio API, the precompiled binaries already make use of it. One selects audio API in effect simply choosing the audio device in mt32emu-qt. Audio API is the leftmost word in the device’s name you see. However, PortAudio is compiled w/o ASIO support to reduce extra dependency in "casual" use case. So, to use ASIO for audio output, you need to recompile PortAudio with corresponding build option (or get an existing binary .DLL with ASIO support). If everything's done properly, you'll see "PortAudio: (ASIO) ..." among the available audio devices. But if you're on Windows 7, I suspect there is little point to bother with this as you can use WASAPI (even in exclusive mode) via PortAudio API out of the box.

What type of sound card are you using?

Sorry to revive an old thread but I ran into the same issue with a new setup. Basically, if I use an external MT-32 and external synth together, it syncs up fine, but if I try and use MUNT with my external synth, and mix them together, there is noticeable lag in playback.

Now using Win 7 Pro, but still, MUNT lags behind each note quite a lot. Not sure if I can slow my synth down or reduce latency with MUNT.

Not sure if any changes have been made since I checked a year ago? I see a new download was available recently.

Looks like using the WDM-KS driver works. I just didn't realise it was an option because at the default settings of 0, 0 and 0 it will fail, you have to set it to 10/40/15 or a usual combination.

KS = Kernel Streaming, it works outside of normal memory and so has no lag pretty much.

Still a bit of lag with this setup. Much lower than the original post but still enough to render non functional. Sergm, any update to the situation for ASIO support?

No idea how to recompile or use a binary DLL, or I would do that 😀

Congrats, Spikey, things have improved a bit. First of all, I added "Building" section to the readme, so it should be less pain to build the Qt app now. On the other hand, I really don't plan to include support for ASIO in the near future. In my setup, PortAudio / WDM-KS gives 3 ms of total latency, not sure if you can get less with ASIO:

1Using Analogue output mode: Accurate
2Using sample rate: 48000
3PortAudio: using audio device: 5 "API: Windows WDM-KS" "Speakers (Realtek HD Audio output)"
4PortAudio: audio latency (s): 0.003
5PortAudio: MIDI latency (s): 0.003

With WASAPI, I get 22 ms (not in the exclusive mode), and the WinMME driver gives (chunk 1ms, audio latency 12ms):

1Using Analogue output mode: Accurate
2Using sample rate: 48000
3WinMMAudioDriver: Using 12 chunks, chunk size: 48 frames, buffer size: 576 frames.
4WinMMAudioDriver: Using WaveOut device: 0

So, I think it's worth trying to lower the latency with the means you already have.

Just want to remind you that resampling isn't your friend here. The resampler built in the mt32emu-qt ensures additional latency of about 10 samples, not millis. But it isn't linear phase, so beware. Best would be to ensure the output sample rate of your audio to match 32000/48000/96000 Hz. Perhaps, using SPDIF output may help.

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.

I appreciate your time and will try those solutions. I believe my main synth has a 48 KHz sampling rate option so I will try it as well.

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.

Thanks sergm 😀

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.