Correction in DOSBox-r3873-mt32 patch \ VOGONS

Correction in DOSBox-r3873-mt32 patch

Topic actions

First post, by truth_deleted

Posted on 2014-12-02, 04:34

truth_deleted Offline

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:

1--- midi_mt32.cpp	2014-12-01 23:07:00 -0500
2+++ midi_mt32-NEW.cpp	2014-12-01 23:05:20 -0500
3@@ -121,6 +121,13 @@ bool MidiHandler_mt32::Open(const char *
4 		playedBuffers = 1;
5 		thread = SDL_CreateThread(processingThread, NULL);
6 	}
7+	else {
8+		sampleRateRatio = MT32Emu::SAMPLE_RATE / (double)synth->getStereoOutputSampleRate();
9+		minimumRenderFrames = (MINIMUM_RENDER_MILLIS * synth->getStereoOutputSampleRate()) / MILLIS_PER_SECOND;
10+		framesPerAudioBuffer = (AUDIO_LATENCY_MILLIS * synth->getStereoOutputSampleRate()) / MILLIS_PER_SECOND;
11+		audioBufferSize = framesPerAudioBuffer << 1;
12+		audioBuffer = new Bit16s[audioBufferSize];
13+	}
14 	chan->Enable(true);
15 
16 	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 1 of 17, by sergm

Posted on 2014-12-02, 07:40

sergm Offline

Rank Oldbie

Rank: Oldbie
Posts: 937
Joined: 2011-02-23, 16:37

Thanks, that's fixed now.

Reply 2 of 17, by truth_deleted

Posted on 2014-12-02, 08:12

truth_deleted Offline

I tried. 😀

I can't wait to try your updated dosbox patch which enables the recent mt32 additions, especially the analog output emulation modes!

Reply 3 of 17, by sergm

Posted on 2014-12-02, 08:24

sergm Offline

Rank Oldbie

Rank: Oldbie
Posts: 937
Joined: 2011-02-23, 16:37

Heh, it depends on your audio system quality... I expect you've got high-end stuff? I doubt something can be distinguished with a couple of cheap noisemakers 😀

Reply 4 of 17, by truth_deleted

Posted on 2014-12-02, 10:02

truth_deleted Offline

Oh well. 🙁 I guess my Creative T20s fall into the latter category, but I can always imagine!

Reply 5 of 17, by marooned_on_mars

Posted on 2014-12-07, 01:47

marooned_on_mars Offline

Rank Member

Rank: Member
Posts: 359
Joined: 2006-01-23, 18:47
Location: MoonBase2

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

1make[3]: Entering directory '/home/andoru/sources/dosbox/src'
2g++ -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
3mv -f .deps/dosbox.Tpo .deps/dosbox.Po
4g++  -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
5gui/libgui.a(midi.o): In function `__static_initialization_and_destruction_0':
6/home/andoru/sources/dosbox/src/gui/midi.cpp:95: undefined reference to `MidiHandler_mt32::GetInstance()'
7collect2: error: ld returned 1 exit status
8Makefile: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

Posted on 2014-12-07, 02:04

truth_deleted Offline

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 7 of 17, by sergm

Posted on 2014-12-07, 09:41

sergm Offline

Rank Oldbie

Rank: Oldbie
Posts: 937
Joined: 2011-02-23, 16:37

Hmm, not sure why to compile it daily. Hopefully, neither munt nor DOSBox sources get updated so frequently 😀

Reply 8 of 17, by truth_deleted

Posted on 2014-12-07, 10:07

truth_deleted Offline

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

Posted on 2014-12-07, 13:34

sergm Offline

Rank Oldbie

Rank: Oldbie
Posts: 937
Joined: 2011-02-23, 16:37

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

Posted on 2014-12-07, 23:29

truth_deleted Offline

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

Posted on 2014-12-08, 21:51

marooned_on_mars Offline

Rank Member

Rank: Member
Posts: 359
Joined: 2006-01-23, 18:47
Location: MoonBase2

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

Posted on 2014-12-08, 23:33

truth_deleted Offline

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

1mt32.analog=
2
3Digital = 0
4Only digital path is emulated. The output samples correspond to the digital output signal appeared at the DAC entrance. Fastest mode.
5
6Coarse = 1
7Coarse emulation of LPF circuit. High frequencies are boosted, sample rate remains unchanged. A bit better sounding but also a bit slower.
8
9Accurate = 2 - default
10Finer 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.
11
12Oversampled = 3
13Same 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 13 of 17, by bloodbat

Posted on 2014-12-11, 06:32

bloodbat Offline

Rank Oldbie

Rank: Oldbie
Posts: 796
Joined: 2009-12-06, 07:11

It should work (using digital) even with an out of date .conf file.

Reply 14 of 17, by sergm

Posted on 2014-12-11, 07:46

sergm Offline

Rank Oldbie

Rank: Oldbie
Posts: 937
Joined: 2011-02-23, 16:37

It works whatever is in the conf file. To recreate the conf file "config -wc" or "config -wcp" (for SVN builds) may be used.

Reply 15 of 17, by SedrynTyros

Posted on 2015-01-08, 23:47

SedrynTyros Offline

Rank Member

Rank: Member
Posts: 119
Joined: 2012-07-24, 21:44

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.

Reply 16 of 17, by truth_deleted

Posted on 2015-01-09, 01:10

truth_deleted Offline

The patch is working as intended. The patch command is designed to compensate for the offset, so it is not an issue.

Reply 17 of 17, by SedrynTyros

Posted on 2015-01-09, 05:55

SedrynTyros Offline

Rank Member

Rank: Member
Posts: 119
Joined: 2012-07-24, 21:44

truth5678 wrote:
The patch is working as intended. The patch command is designed to compensate for the offset, so it is not an issue.

Righto, hombre!

Go to top of page Go to top of page

Back to MT-32 Development