I have tried running the v12 PCem on 2 of my machines : i7 4790K Desktop and Core M Dell Tablet, both running Windows 10 Pro, and on both I face the audio lags which seem to be distracting in an otherwise, a very good effort of emulating the older PCs.

I have read over here about these lags, but couldn't get a conclusive outcome yet if this issue is solved. There was a thread here https://pcem-emulator.co.uk/phpBB3/view ... =audio+lag regarding compiling again with two modified files by the admin, SarahWalker, and not sure if those have been implemented in this latest build.

I have tried compiling but as I have never compiled in windows before (all I used to compile were just MUNT and Timidity in TinyCore Linux), I face one hurdle after another when it comes to compiling pcem (a long story - spent 4 days without success but many errors - before coming here for help). I also grabbed the all-in-one compiling file, where I just run the batch file after placing the downloaded files into the source directory, with the 2 modified files replaced in the src dir, taken from the above link. But that resulting, built executable had worse audio skipping...

Is this problem completely solved yet? Or the audio lag is still persistent? If it has been successfully recompiled, will it help if I can try that built binary on my systems?

MIDI music and CD audio in games (playing Entomorph: Plague of the Darkfall) plays nice. No skipping and smooth. Just the sound effects are lagging a few microseconds, I think. It's quite distracting. And more apparent in dialogues - the lip syncing is out (Philip Marlowe - Private Eye).

Thank you for any info.

And thank you for this great emulator. It brings back lots of good memories for installing and playing around with DOS in classic machines and Windows95. If only the audio lag is solved, it would be perfect. (I have some Windows 95 games that I would love to continue playing in Win95 setup , and so far PCem is the only one that could make this happen, speed-wise and accuracy-wise, and my focus is the 430VX with Win95 gaming.

Last edited by Malik on Wed 07 Jun, 2017 4:29 am, edited 2 times in total.

Malik wrote:I face one hurdle after another when it comes to compiling pcem (a long story - spent 4 days without success but many errors - before coming here for help).

Yes, compiling PCem is a bit scary for those who are new to the emulator, especially when there is a lot of files involved, you have no idea what file you should start with.

Battler wrote:It might be the really old GCC Sarah is still compiling with, since it does seem that her builds have this lag, while builds compiled with newer GCC (eg. 5.x or 6.x) do not have that lag.

Well, Sarah reduced the audio buffer so that it would not be noticeable enough, and I doubt that she will change it again just to benefit one user.

This may be irrelevant, but I was told it depends on how powerful your host machine is. I have a Intel Core i7 with 16GB RAM installed, and I can run most games in PCem at a reasonable speed, but I am not sure if I can run a lot of FPSes with 3DFX/Voodoo enabled.

I still notice the lag. I tried DoomII and Gods. A very small lag, but still noticeable. About ½ or ¾ of a second lag. I tried this in a i486DX2-66 configuration with SB16 card.

If anyone does NOT have any lag, is it possible to share the executable so that I may try it on my machine?

I'm just wondering if this problem is only faced by a few or is prevalent throughout.

I guess only those game will notice the lag?

Thanks.

Edit: Pre-rendered screens seem to be okay. The intro in Chaos Overlords seem to play accordingly. The voice comes and stops with the speaking character in that cutscene. I've yet to try to play some movies to check.

Edit 2: Yes, I tried with the latest gcc 5.3.. with the src folder from the main pcem download here.

@Katakis, The first number is not bit rate but Words divided by that second number, i thought that it was bit rate too, but we covered that topic extensively in here https://pcem-emulator.co.uk/phpBB3/view ... +lag#p4322 and kindly people (Battler) explained everything to me, i advice you to read all of this.

I looked back at the previous link once more, and took the hint and tried deleting the OpenAL32.dll in the PCem folder, the one that comes with the official PCem release here.

And since I am using my own compiled executable, it doesn't need the version that is included with the release, I guess.

Now there is no more lag.

Thank you!

P.S. Is it possible to fix this on the next release so that end-users (like me, who are not very experienced in compiling on our own) can directly experience PCem without the need to re-compile and use the newer OpenAL? Thanks again.

Malik wrote:
P.S. Is it possible to fix this on the next release so that end-users (like me, who are not very experienced in compiling on our own) can directly experience PCem without the need to re-compile and use the newer OpenAL? Thanks again.

That would be great! Provided there's no disadvantage on using the newer version... what do you say Sarah?

basic2004 wrote:
You should copy libstdc*.dll to PCem which you compiled.

Thanks, this part I already figured out in edit #2 of the previous post.
But this is good piece of information for future users.

Now the problem is I can't delete OpenAL32.dll from PCem directory to lower the latency, the compiled executable it is still dependent on it.
I read people delete OpenAL32.dll without problems after compiling the latest dev source.
What do you think can be the problem?

EDIT:
Okay, the stuttering was actually gone with the compiled dev version but it still had some lag compared to dosbox that I'm used to.
Ive lowered the buffers to 48000/50 in imb.h and now everything is perfect.

I don't know if it is already been mentioned by the buffers should undoubtedly be part of the configurations for the end user, without having to tweak the source code learning to compile it.

Okay the OpenAL32.dll actually exist but in the MinGW or Windows directory somewhere and the PATH environment variable points to it.
So users who delete OpenAL32.dll from PCem folder actually use a newer OpernAL32.dll from MinGW that does not stutter.

So everything seems to be in order, just compile the latest dev build and lower the buffers to 48000/50 in ibm.h and the delay will be negligible.
Note that I had to include the newer OpenAL32.dll from mingw\gcc-5.3.0-3\bin to PCem provided with the all-in=one compilation.

I would like to add that, as a newbie, like me, I HIGHLY recommend Batttler's latest 86Box build (preferably the "Optimized Builds" by Battler.

His build is a fork of PCem but has many improvements including no-lag audio from the download, and will save many, many headaches of compiling and getting the dependencies for the compilers and so on, for the sound lag issues.

His build is even better than my own compiling, I think, for eliminating the audio lags. I feel it's as good as playing the games in Dosbox.

And there are many desperately needed shortcuts included in Battler's 86Box, like Ctrl-Alt-Del shortcut and switch to full-screen shortcut, and the ability of directing MIDI to MUNT - the MT-32 Emulator, even if using any sound card lower than a SB16. (In official PCem, you can't select MIDI out if the sound card is from a previous generation from a SB16).

Thanks a lot, Battler! I'm now using solely your build now (Haswell optimized - in both my desktop and laptop)

(Sorry Sarah, that I needed to recommend Battler's 86Box build here. But I still would like to suggest to update on the sound lags in the official PCem. It's an excellent emulator btw, and I can safely retire my actual 486 and Win9x machines, thanks to you too and Tom(?).)

Malik wrote:And there are many desperately needed shortcuts included in Battler's 86Box, like Ctrl-Alt-Del shortcut and switch to full-screen shortcut, and the ability of directing MIDI to MUNT - the MT-32 Emulator, even if using any sound card lower than a SB16. (In official PCem, you can't select MIDI out if the sound card is from a previous generation from a SB16).

While you get the selection in 86Box for any card, the MPU-401 is still only active if you use the SB16 or AWE32. Now maybe I should add a checkbox for MPU-401 so that you can use it as an add-on device with other cards as well, but of course that would be ignored when the SB16 or AWE32 is selected.