OmerMor wrote:

sergm, I see you're quite active these days on the emulator - that's great.
Can you please explain to a layman like me why you are developing so many different audio drivers (winmm, port, alsa, oss, pulse, qt) and what is the difference between them?

The shortest answer: I love this work 😀

Btw, you could also notice I ignore DSound and WASAPI. Though, the trues is we initially wanted only QAudioOutput as the only audio interface. However, this appeared to be the worst way for the task of realtime MIDI synth since audio timing (i.e. number of played samples at the moment) implemented in QAudio in ridiculous way. Moreover, as I recenty found, QAudio driver works on Win and Linux only. OSS isn't supported at all, and on Mac it's just silent (don't know the reason why).

So, we tried PortAudio. Much much better, but still not perfect. I even added some improvements in PortAudio itself. But it appeared to be easier to write my own driver for every audio platform we wanted to support than cure PortAudio. 😀 Thus, we have drivers for platforms which PortAudio performs worst on. Generally, these enable even more accurate audio timing and reduced latency.

Although, the hardest problem is that particular audio card drivers can affect the timing accuracy (personally encountered on Realtek codec) and this is fatal. 🙁 So, we have an option "Use advanced timing". If set, the synth tries to get audio timing from audio API, and every error affects rendering accuracy.

If this option is not set, we estimate audio timing on the basis of sample time elapsed for actual rendering, compute actual sample rate of audio output device (either hardware or software mixer of the OS / sound server), and use average values. This way allows perfect rendering (with errors about 0-2 samples) but has longer recovery period in case of x-run or high CPU loads. By default, this way is used to workaround possible timing issues caused by buggy audio drivers / mixers / servers, etc. But the user always has an option.

Thanks for the explanation.
I'd still love to know a little more about each driver - assume I never heard about any of them. I actually never knew there were so many audio driver architectures.

sergm,

Man, that's bad news, I have a Realtek codec in my mainboard! 🙁

However, I've never bothered to install Realtek drivers. I just use Microsoft's built-in drivers included with Windows 7.

Have you tested your Realtek codec using Microsoft drivers? Does it make any difference?

Kind regards.

Using MS drivers for any device will generally give you nothing but the basic features and arguably because of it, the most stable system. Any reason why you would choose MS drivers above that written by the manufacturer?

I normally install the manufacturer's drivers in order to get more functionality, but in this case I just didn't need anything else.

I don't need special effects or equalizers, so Microsoft's drivers fill my audio needs perfectly fine.

@ OmerMor:
There's nothing special, since developers of almost every OS tend to invent original audio API.
The nice exception is OSS – de-facto standard for POSIX systems. As I noted above, QAudio ignores OSS existing, and PortAudio keeps audio latency at some ridiculous level. Instead, our OSS driver allows lowest latencies supported by the system. For example, my FreeBSD install finely works at 16 ms, whereas PortAudio has the minimum of 48 ms.

Though, OSS is also supported in some Linux distros, ALSA is the main audio API there. While both QAudio and PortAudio support ALSA, nasty problems present in some configurations provided by some distro maintainers. In particular, Ubuntu is configured with PulseAudio, and all the audio output directed to ALSA default device is redirected to PulseAudio server. As a result, PortAudio refuses to calculate timing at all. In contrast, our ASLA driver works nice in this configuration thanks to damn good emulation provided by PulseAudio server itself. We have specialized PulseAudio driver as well.

As for Windows audio systems, we only support Windows multimedia API. PortAudio performs pretty well on Windows, but our WinMM driver is somewhat superior in both latency and timing accuracy. Pity, but v18 of PortAudio had problems with DSound regarding timing, and v19 of PortAudio has no support of accurate timing for DSound at all. Moreover, DSound is deprecated by MS guys, so we rather won’t support it. I consider making specialized driver for WASAPI (for Windows Vista and above) in case the minimum latency of 35 ms provided by the current WinMM driver implementation won’t be small enough.

Regarding Mac OS X, I was satisfied how PortAudio performed there as for v18. But again, in v19 they broke timing accuracy (though, one bug related audio latency reported is fixed). Now, PortAudio reports sample output time by 30 sec (!!!) forward against the current time. Luckily, this can be easily fixed setting MIDI latency to 30000 and above in the audio properties dialog. But if it continues, I’ll end up with CoreAudio driver as well. 😀

@ Leolo:
I think, there're a number of codecs from Realtek, and driver quality varies between OS versions as well. So, my personal experience doesn't necessary indicate having Realtek codec is anyway a bad idea. It just indicates that driver quality can surely make problems with timing regardless of audio API used. 😀

But you always can test how good is your system at that with the help of test MIDI driver 😀

First off. Great work on improving the emulation. I've been comparing it to my MT-32 and it is getting very close. Kudos to kingguppy, sergm and other commiters!

I've been following the commits on git. git log ftw. Testing anytime there is a major update.

Getting to the point, do you have any plans on improving the Linux GUI? What is there, is nice, but I'd like it if it more closely matched what is on the actual LCD, and what the actual buttons on a MT-32 are. I'm probably one of the few who actually run the emu as a desktop app, but I do like seeing the messages from the games come up.

Minor feature request. The Linux app, also does not have an icon associated with it. I'm tempted to fix this myself, but I do not want to step on any toes here, and I'm sure someone else could do it better/faster if motivated.

No, there's no plans on developing Linux-only driver any further. Instead, we started Qt-based cross-platform application. It features nicer GUI with LCD, tray icon and optional balloon messages about both client connections and LCD text changes. I recommend you to try this one (it lives in mt32emu-qt branch).

sergm wrote:

Instead, we started Qt-based cross-platform application. It features nicer GUI with LCD, tray icon and optional balloon messages about both client connections and LCD text changes. I recommend you to try this one (it lives in mt32emu-qt branch).

I gave it a try. Didn't work. It does not seem to like or find my control rom even though the old GUI and command line version support it just fine.

So far, I find the new GUI a little lacking. I'm normally not a fan of qt apps. IMHO they never look as good as gtk. I'm sure most of that being my Debian does not have a good skin for qt. I was more imagining something that actually looked like a MT-32 as a border-less window.

But, that is just the dialog itself. If it worked for me, I'm curious if the pop-up balloons look better.

We don't really want it to look exactly like the real thing, though.
And yes, currently it recognizes two sets of ROMs only (see Re: Munt Reloaded - Development ).

Alright, I have it built and working now. It is growing on me a bit. I love that it uses a tray icon. The icon itself is a bit bland. Also, the bubbles could use libnotify instead of their own deal, but that is probably because that is not cross platform.

The window tittle is also "MainWindow" should say "Munt MT-32 Emulator" or something.

Yes, and actually, I just used balloon system from Qt. Though, it seems faked on Mac, and we may reconsider using it (maybe towards libnotify & Co). 😀

Btw, I updated the patch for DOSBox. And I think of adding LCD balloons to the patch.

smf2wav also updated. It seems no more troubles with the "China bug" 😀
Re: Munt Reloaded - Development

Thanks for the DOSBox update, Serg. Been looking forward to that! Hopefully some more of your work will find its way into the next ScummVM update.

GUI is looking good guys. Love the channel data display! This is from the recent git branch.

Quick stupid question: Where can i get munt reloaded? There is no website for it and the sourceforge page has no downloads...

edit: i'm looking for a windows version btw.

Quick stupid 😀 answer: at GitHub. BTW, "munt reloaded" has been actually reloaded into the main Munt, so it's gone...

Sources:
https://github.com/munt/munt

Development / test binaries:
https://github.com/sergm/munt_devel/downloads

MUNT currently does not seem to implement controller 64 ("hold" pedal) correctly under non-default assign modes. Please consider the attached MIDI file.

It plays a sequence of four notes twice, the first time with assign mode POLY1 (the default), the second time with assign mode POLY3. POLY3 will use more partials, but has the advantage that previous notes on the same key will not get cut off.

On a real LA module, releasing the hold pedal (controller 64 = 0) releases all sustaining notes. On MUNT, note C5 keeps playing even after hold off (controller 64 = 0) is received during the second iteration, while assign mode POLY3 is active. This is not correct.