VOGONS


MUNT-32 very slow

Topic actions

Reply 41 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

sergm, I just came home to test...

wow! what a big difference! still slow like hell compared to MT-32 emulation inside dosbox, but....

I tested

Use ring buffer renderer > ON
- Chunk length = 32
- Audio latency = 256
- MIDI latency = 40

And everything change a lot, from 10 times slower music, to just 2 times slow 😀

Still CPU is 100% all the time, but at least, I can hear the music now, not very good, but much much better!

Reply 42 of 55, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

OK, I think DOSBox uses hardware accelerated DSound buffer in your case but WinMME never does (KSMixer is always used). But I still don't understand why it degrades the performance so much... Not sure, but PortAudio may also use a hardware DSound buffer. Try playing with it as well.

Also, KSMixer uses the highest sample rate to produce output. This means, when you set 44100 Hz as the DOSBox sample rate and Windows driver / mt32emu_qt set to the fixed sample rate 32000 Hz, KSMixer DOES perform sample rate conversion 32000->44100 programmatically irrelative to what sound card is used. So, setting DOSBox mixer to 32000 Hz may also help as KSMixer should (if there is no other audio sources) set its sample rate to 32000 Hz avoiding the conversion (of course, in case the sound card supports this frequency). This trick relates to the Windows driver mostly as I haven't implemented DSound output there yet (and I think will never do, I'd rather add WASAPI support, Windows XP will die soon anyway).

Reply 44 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

Im so sorry sergm, my knowledge of audio are is...mm... not good 😵 I cant understand the link

Thats why maybe, what I will say, is very stupid idea, but if the problems came from the windows Winmm, dsound, etc using a driver like asio4all will not help?

Thanks

Reply 45 of 55, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Although, ASIO is primarily targeted to reduce _latency_, it can also help to get rid of extra overhead that may plague the audio system. So, actually, this is not a bad idea. But before trying to mess with it, we should ensure the problem lies exactly in the audio system.

I'd propose two more tests if you like... 😀

1. Among others, mt32emu_qt has "AudioFileWriter" driver. This thing just writes the synth output to a file you name without any overhead. But unlike the batch conversion we've already tried, it does the job _in real time_, so you'll be able to compare the CPU load fairly.

2. WinMMAudio driver with "Use ring buffer render" option turned ON, allows you to further reduce the chunk length. Basically, to get as close as possible to what DOSBox really does you should set chunk length to "1". This will instruct the renderer to perform rendering by minimum available slices (it appears 1.5 millisecond on my "big" system). This also makes the CPU load as smooth as possible but on the other hand, it makes the process switching overhead greater.

Reply 46 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

Hi sergm

I did a test like you say:

-Played "Larry 1 MT-32 midi" with default driver, give me 40-65% CPU, but if I move a window for example, or open a notepad, whatever, CPU goes to 100% and sound became slow, with glitches, etc exactly same happen if I open a game using ntvdm

-Played "Larry 1 MT-32 midi" with "AudioFileWriter" driver, CPU is still high, little lower 25-50%, and same, if move windows, open notepad, etc CPU goes to 100% BUT, the output wav file, sound great, perfect larry music , without any delay, glitches, etc

It seems, that even with CPU at 100% the midi "plays/record" great, because the wav file have perfect music

Then I tested the "Use ring buffer render" with chunk length to "1", and the difference is very big, now the music in some games like 4D Sport boxing, is good, not slow, except in some momments

Resume:

Use ring buffer render ON
chunk length to "1"
Audio Latency: 16
MIDI latency: 15

Give me a good speed in old games now! still CPU usage is very high compared to dosbox, but at least, much better

Reply 47 of 55, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Glad you have now it working as you want.
Side note: the setting "Audio Latency: 16" is totally impossible on my system. Anything lower than 35 leads to cracklings 😀
And anything lower than 30 milliseconds is unreliable due to specifics of KMixer of Windows XP. Vista+ system allows lower latencies but I anyway don't support it.

Reply 48 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

Hi sergm, I tried with latency to 35, but the problem is that I can feel a little delay in the sound... but maybe is just me jejje

Im so sorry for all the time you lost with this problem, but at the end everything was ok, because from first post to last one, everything change from "sound like shit" to "sound good"

This is very useful to me, because the only DOSBox version I found with good vsync is this

Yet another attempt at vertical sync

But sadly this version dont have MT-32 integrated, and I need to use the windows driver

All other DOSbox version over there, have a terrible vsync using surface, ddraw or overlay, but this, is perfect

Reply 50 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

I just build a scummvm for my personal use, finally I did, but was a pain in the ass

Compile small stuff, like assembly code is easy, but all this Visual stuff, with hundred of files, puff... I get lost

In Linux, with the config and makefile, is much easy if no error happen, Visual just.. is not my friend, always I get errors!!! 😊

If you like Megadrive, compile a dosbox for me, and I will make something for you, demo, engine, game, etc 😀

Reply 52 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

Heh, MinGW is definitely for you then 😀

Is possible to compile dosbox with mingw? will be great, because I use mingw often

I remember time ago, I apply the diff the guy in the post of vsync patch give, to the source of dosbox, and totally fail to compile 😵

On this time, I was using windows 2000, and VC 2010 was not a option, and I tried to compile with VC 2008..jeje

Im very bad 😊 😊

Reply 53 of 55, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

So, you have great potential then 😀
I compile that DOSBox+MT-32 build using exactly VS 2008 Express. I also tried MinGW but was disappointed with the performance I got. 🙁 Though, hopefully things change and MinGW will improve...

Reply 54 of 55, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

I will tried to do, I just downloaded VS 2010 express the other day, for compile scummvm, then is still in my computer, sadly Im leaving my house in a couple of days..

My work is... well.. I travel all the time, two weeks in my house, on month traveling.... Is so difficult to do any large personal project

Thank for all, If I found time, and don´t failt to build a custom dosbox, I will send to you

Greetings