First post, by truth_deleted

User metadata

With thread=off, the DOSBox-r3873-mt32 patch causes a dosbox error; it occurs after the mt32 emulated device is opened. However, thread=on does work.

Modified code which corrects the error:

--- midi_mt32.cpp	2014-12-01 23:07:00 -0500
+++ midi_mt32-NEW.cpp 2014-12-01 23:05:20 -0500
@@ -121,6 +121,13 @@ bool MidiHandler_mt32::Open(const char *
playedBuffers = 1;
thread = SDL_CreateThread(processingThread, NULL);
+ else {
+ sampleRateRatio = MT32Emu::SAMPLE_RATE / (double)synth->getStereoOutputSampleRate();
+ minimumRenderFrames = (MINIMUM_RENDER_MILLIS * synth->getStereoOutputSampleRate()) / MILLIS_PER_SECOND;
+ framesPerAudioBuffer = (AUDIO_LATENCY_MILLIS * synth->getStereoOutputSampleRate()) / MILLIS_PER_SECOND;
+ audioBufferSize = framesPerAudioBuffer << 1;
+ audioBuffer = new Bit16s[audioBufferSize];
+ }

open = true;

I don't know for sure whether the above added code is the proper solution, but nearly all these lines are required to avoid the above dosbox error where thread=off (same as renderInThread set to false in the code). The above lines are already available where thread=on (renderInThread = true).

Reply 5 of 17, by marooned_on_mars

User metadata
Rank Member

Not sure if it's because of the new patch or it's at my end, but I'm getting this while compiling:

make[3]: Entering directory '/home/andoru/sources/dosbox/src'
g++ -DHAVE_CONFIG_H -I. -I.. -I../include -I/home/andoru/include/ -I/home/andoru/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g -O2 -mno-ms-bitfields -MT dosbox.o -MD -MP -MF .deps/dosbox.Tpo -c -o dosbox.o dosbox.cpp
mv -f .deps/dosbox.Tpo .deps/dosbox.Po
g++ -g -O2 -mno-ms-bitfields -o dosbox dosbox.o cpu/libcpu.a debug/libdebug.a dos/libdos.a fpu/libfpu.a hardware/libhardware.a gui/libgui.a ints/libints.a misc/libmisc.a shell/libshell.a hardware/serialport/libserial.a libs/gui_tk/libgui_tk.a -lasound -lm -ldl -lpthread -L/home/andoru/lib/ -L/home/andoru/lib -lSDL -lpng -lz -lX11 -lGL
gui/libgui.a(midi.o): In function `__static_initialization_and_destruction_0':
/home/andoru/sources/dosbox/src/gui/midi.cpp:95: undefined reference to `MidiHandler_mt32::GetInstance()'
collect2: error: ld returned 1 exit status
Makefile:296: recipe for target 'dosbox' failed

EDIT: Got munt source from git, latest commit at this time is 7e924b1

Last edited by marooned_on_mars on 2014-12-07, 02:13. Edited 3 times in total.

Reply 6 of 17, by truth_deleted

User metadata

I've been compiling from source daily and haven't encountered a compiler/linker error in 32-bit Windows. Perhaps start from unchanged dosbox SVN code, apply patch, and see if error occurs again? Which version of gcc is used?

Edit: also verify that the newest MUNT header files were copied to directories seen by the compiler.

Reply 8 of 17, by truth_deleted

User metadata

Recently, I've noted your frequent updates and have tried to maintain a current build for testing. Fortunately, I don't have to rebuild based on your latest commits to the osx and winmm drivers. 😀

I typically test with SC2000 by Maxis and found that one particular song doesn't play with mt32 driver and thought I built a faulty dosbox, but it turns out the sim was designed that way!

Also, thank you for the patches to dosbox which implement your new analog sound emulation!

Reply 9 of 17, by sergm

User metadata
Rank Oldbie

I've been waited for someone to be able to maintain that (completely despaired to see the lib integrated into DOSBox svn at least). At the end, I realized the better it looks the closer my goal. Btw, even if I still make the updates, this task is now way easier as the hog of release vs. svn patches reduced to absolute minimum (which is actually how it must be).
Now, upon finishing CoreAudio driver and at last saying good bye to disappointing portaudio, I'll add an external C interface - wrapper which allows the lib to be easily used out of C++ scope, e.g. from apps written in other languages like Java. Perhaps, this makes it closer to get the lib integrated if it isn't stuck due to licensing reasons of course...

Reply 10 of 17, by truth_deleted

User metadata

The interface wrapper would be a welcome feature! With time, I think there will be added pressure for gog.com to include mt-32 support for relevant games; although your emulation must appeal to music enthusiasts, too. Also, since scummvm includes the mt-32 emulation without issue, then it should be reasonable to include the same with vanilla dosbox.

I'm always glad to test your emulation additions (and share a build when it is ok). It never ceases to amaze me to hear the high quality midi output available from Munt, especially as compared to the other music options. 😀

Reply 11 of 17, by marooned_on_mars

User metadata
Rank Member

Yesterday I didn't have any time to test out if I can compile DOSBox, but today I cloned the latest git source (commit 59e4764443) and now it worked. Not sure what happened last time, but I don't remember running autogen.sh, so that might be what caused it, I'm not sure though. Will you be able to add any way of changing the analogue output type in the dosbox.conf?

Reply 12 of 17, by truth_deleted

User metadata

Did you recreate the dosbox configuration file with the latest dosbox build with mt-32 emulation? The new file has the analog output types.


Digital = 0
Only digital path is emulated. The output samples correspond to the digital output signal appeared at the DAC entrance. Fastest mode.

Coarse = 1
Coarse emulation of LPF circuit. High frequencies are boosted, sample rate remains unchanged. A bit better sounding but also a bit slower.

Accurate = 2 - default
Finer emulation of LPF circuit. Output signal is upsampled to 48 kHz to allow emulation of audible mirror spectra above 16 kHz, which is passed through the LPF circuit without significant attenuation. Sounding is closer to the analog output from real hardware but also slower than the modes 0 and 1.

Oversampled = 3
Same as the default mode 2 but the output signal is 2x oversampled, i.e. the output sample rate is 96 kHz. Even slower than all the other modes but better retains highest frequencies while further resampled in DOSBox mixer.

Reply 15 of 17, by SedrynTyros

User metadata
Rank Member

Tried patching the DOSBox SVN r3885 source with dosbox-SVN-r3873-mt32-patch.diff and there's now some drift when it patches dosbox.cpp:

"Hunk#1 succeeded at 491 (offset 8 lines)."
"Hunk#2 succeeded at 507 (offset 8 lines)."

It still works, though; this is just an FYI. When I tried patched DOSBox SVN r3876 with this same dosbox-SVN-r3873-mt32-patch.diff there were no such discrepancies with dosbox.cpp.