[Partially-Solved] PCem v12 and Sound Lag

Support and general discussion.
Malik
Posts: 17
Joined: Sat 20 May, 2017 2:43 am

Re: [Solved] PCem v12 and Sound Lag

Postby Malik » Sun 04 Jun, 2017 3:07 pm

Malik wrote:
Battler wrote: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.


I see. Yes, a MPU-401 independent of sound cards will be immensely useful.


Thanks, Battler. Now I can select MPU-401 independent of any sound card installed. That was fast! Thanks again! Very glad!
Dacasks
Posts: 3
Joined: Fri 02 Jun, 2017 4:14 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Dacasks » Sun 04 Jun, 2017 4:07 pm

Geez, just registered. Didn't know the emulator development was up for this amount of drama.
Hope for the best for you.

Anyway, vanilla pcem gives me better performance. I use a Dual Core G3258. Even if I try the optimized 86BOX for dual cores, it gives even less performance... so, if this report serves anything...
It's also less stable indeed, whenever I change the color pallete (16 bit/24) it crashes.

but yeah, the 86box interface for now is a lot better. The screen redimension and everything. I hope v13 incorporate that.
The áudio lag is not much of a issue as the input lag for now. Both forks have annoying amount of it but...

... keep this thing alive!
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Sun 04 Jun, 2017 4:34 pm

- Dacasks: I recommend you disable NukedOPL. I think that's what causes you a performance reduction on 86Box.

As for the crashes, they happen because Sarah put the Direct3D 9 render into its own thread even though Direct3D 9 is known for not being very thread-safe. It doesn't show up much on mainline PCem because Sarah uses an older GCC and that seems to alleviate the problem. I use GCC 6.3.0 and that causes Direct3D 9 to go unstable even if I just compile mainline PCem with it. I'm lucky to be on an older graphics card where DirectDraw is faster so I never really have to use Direct3D, but a lot of people are not.
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Solved] PCem v12 and Sound Lag

Postby James-F » Sun 04 Jun, 2017 4:36 pm

The direct3D option in PCem is great, but it painfully lacks x2 and x3 scaling in fullscreen to lessen the bilinear filtering blur to some degree. ;)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Sun 04 Jun, 2017 4:53 pm

- James-F: It's still threading of a non-thread-safe API. The fact the distributed mainline PCem binaries do not show the problems is sheer luck.
basic2004
Posts: 118
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Solved] PCem v12 and Sound Lag

Postby basic2004 » Sun 04 Jun, 2017 4:54 pm

James-F wrote:The direct3D option in PCem is great, but it painfully lacks x2 and x3 scaling in fullscreen to lessen the bilinear filtering blur to some degree. ;)

I felt OpenGL in PCem SDL2 + wxWidget is greater than D3D what is newest feature. but I didn't speed test yet :)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Sun 04 Jun, 2017 5:08 pm

The non-SDL version of PCem really needs an OpenGL renderer. :p
User avatar
leilei
Posts: 436
Joined: Fri 25 Apr, 2014 4:47 pm

Re: [Solved] PCem v12 and Sound Lag

Postby leilei » Sun 04 Jun, 2017 11:22 pm

Vanilla PCem builds are profile optimized. No way will tossing in random CPU-specific tuning flags will match the results of that. If there's any switch that helps come close (but not quite), it's -flto


(I also believe we've been here before as well)
also mooch being banned here for a year so far hasn't changed their toxicity
Dacasks
Posts: 3
Joined: Fri 02 Jun, 2017 4:14 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Dacasks » Sun 04 Jun, 2017 11:44 pm

Battler wrote:- Dacasks: I recommend you disable NukedOPL. I think that's what causes you a performance reduction on 86Box.

As for the crashes, they happen because Sarah put the Direct3D 9 render into its own thread even though Direct3D 9 is known for not being very thread-safe. It doesn't show up much on mainline PCem because Sarah uses an older GCC and that seems to alleviate the problem. I use GCC 6.3.0 and that causes Direct3D 9 to go unstable even if I just compile mainline PCem with it. I'm lucky to be on an older graphics card where DirectDraw is faster so I never really have to use Direct3D, but a lot of people are not.


Thanks for answering/input!

But... it was already uncheck. But really, it's not that noticeable, but it's there.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Mon 05 Jun, 2017 1:30 pm

leilei wrote:Vanilla PCem builds are profile optimized.

That's true, but IMHO, profile optimization is really a band aid. It makes PCem faster for the specific usage Sarah profiled it for (which I guess would be the games she plays), with no guarantee of improvement when doing anything else.

No way will tossing in random CPU-specific tuning flags will match the results of that.

Then I'm sure you have a good amount of detailed data to back up your statement. Especially since last I remembered, neozeed's tests proved optimization and tuning flags can improve performance if done right.
SarahWalker
Site Admin
Posts: 1333
Joined: Thu 24 Apr, 2014 4:18 pm

Re: [Solved] PCem v12 and Sound Lag

Postby SarahWalker » Mon 05 Jun, 2017 5:29 pm

Battler wrote:As for the crashes, they happen because Sarah put the Direct3D 9 render into its own thread even though Direct3D 9 is known for not being very thread-safe.

Actually the threading situation hasn't really changed. It's gone from splitting D3D calls between the UI thread and the emulation thread, to splitting them between the render thread and the UI thread - exactly the same split as before.

GCC version will have nothing to do with this, unless 6.3.0 is broken (which is possible). So if you've actually had increased instability as a result of that change, the most likely alternatives are :

  • You've screwed up the merged from mainline
  • You have bad D3D libraries
  • You have the worst graphics drivers in the world

None of which I can do anything about.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Mon 05 Jun, 2017 7:21 pm

GCC 6.3.0 certainly does appear to be full of problems, the initial MingW release of it produced executables that crashed on Windows XP but shouldn't, that was subsequently fixed. However, I blame the Direct3D threading for one reason - DOSBox also does it (via SDL) and I have the same kind of problems (crashes and freezes) there, in fact in DOSBox it's worse, it freezes as soon as I switch to Direct3D.

SarahWalker wrote:You've screwed up the merged from mainline

At first I did but later I just replaced my merge attempt with a direct copy+paste, which while it alleviated the problems, they apparently still are there.

SarahWalker wrote:You have bad D3D libraries

I'm on Windows 10, specifically Creator Update (the one released this year), and Direct3D seems to be exceptionally bad on this (my window-patched Dicrect3D.dll in my GTA SA directory used to work perfectly in the Anniversary Update of Windows 10, but has been glitching badly ever since I updated to the Creator Update), though I also received reports about it from other users of AMD graphics cards, and I have a Radeon as well, so there seems to be a correlation.

SarahWalker"}You have the worst graphics drivers in the world[/quote]
Per the above, yes, it does seem the AMD Radeon drivers do Direct3D 9 badly.

[quote="SarahWalker wrote:
None of which I can do anything about.

You could write an OpenGL or Direct3D 10 (or 11) renderer, that should work better. Well, I personally use DirectDraw because it's faster on my card, but OpenGL might be on par with DirectDraw. On DOSBox, I just use OpenGL and it works like a charm.
SarahWalker
Site Admin
Posts: 1333
Joined: Thu 24 Apr, 2014 4:18 pm

Re: [Solved] PCem v12 and Sound Lag

Postby SarahWalker » Mon 05 Jun, 2017 8:11 pm

OpenGL has genuinely massive problems with executing calls on a different thread to the UI. That's why PCem has a Direct3D renderer instead - the GL one never really worked.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Mon 05 Jun, 2017 8:14 pm

Then why not consider a Direct3D 10 or 11 render? That actually is thread-safe, at least according to Microsoft themselves. I think the emulator would massively benefit from it. :p
basic2004
Posts: 118
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Solved] PCem v12 and Sound Lag

Postby basic2004 » Tue 06 Jun, 2017 12:29 am

Someday this will support Vulkan renderer after supports OpenGL and D3D11/12. OpenGL is good but slow, I using SDL2+wxWidgets in Windows...
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Solved] PCem v12 and Sound Lag

Postby James-F » Tue 06 Jun, 2017 4:40 am

I find the sound lag practically gone or at least on DOSBox level with 48000/50 set ibm.h
Obviously the default 48000/20 is x2.5 times as much lag.
Malik
Posts: 17
Joined: Sat 20 May, 2017 2:43 am

Re: [Solved] PCem v12 and Sound Lag

Postby Malik » Tue 06 Jun, 2017 8:30 am

James-F wrote:I find the sound lag practically gone or at least on DOSBox level with 48000/50 set ibm.h
Obviously the default 48000/20 is x2.5 times as much lag.


Yes, as Battler has implemented in his ***build*** too. That was why I mentioned about that but I didn't see the source there until I read this. It's corrected ***there*** too.

If this is the main cause of the sound lag can it be corrected and consolidated in future official release?

I'm just wondering why not many have this complaint of sound lag. Either this is only noticed by some, like me, who mostly use this for gaming purposes, or, it's machine specific? Maybe not experienced by the authors?

Edit: I must also bring to notice, that when I compiled myself the original source of PCem and deleting the included openAL library, I was able to eliminate most lags, even without the above changes. Battler's ***build*** improved it even further.

Edit2: I checked the FMV in Crusader No Remorse (briefing video for first mission) - there's a very tiny lag in audio during that movie. But gameplay is good. No perceivable lag. (430VX, P133, 128MB RAM, S3 Virge DX, SB Prov2,DOS6.22, in i7 4790K )


But generally, with all this change, I guess it's almost the real thing. :)
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Solved] PCem v12 and Sound Lag

Postby James-F » Tue 06 Jun, 2017 8:57 am

Malik wrote:But generally, with all this change, I guess it's almost the real thing. :)

Not really. :)
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Solved] PCem v12 and Sound Lag

Postby Battler » Tue 06 Jun, 2017 1:48 pm

- basic2004: Vulkan is useless, a lot of PCem users are on crappy hardware and a lot of them are in quite financially messed up countries so they can't just go out and buy a new PC, so it would benefit too few people to be worth the effort.
SarahWalker
Site Admin
Posts: 1333
Joined: Thu 24 Apr, 2014 4:18 pm

Re: [Solved] PCem v12 and Sound Lag

Postby SarahWalker » Tue 06 Jun, 2017 4:44 pm

James-F wrote:I find the sound lag practically gone or at least on DOSBox level with 48000/50 set ibm.h
Obviously the default 48000/20 is x2.5 times as much lag.

On my machine 48000/50 gives appalling choppy audio output. Hence why I've not made this change.
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Solved] PCem v12 and Sound Lag

Postby James-F » Tue 06 Jun, 2017 5:42 pm

People use various machines to run PCem, so maybe make this buffer length user configurable so the user can find the right value for his system.
In DOSBox this value called "blocksize" and is configurable by the user.

Maybe make this division value an integer (48000/X) and let the user adjust it from 10 to 100 in the configuration menu, where 100 is the lowest latency but requires the most powerful machine.
You can obviously reverse it in the UI to 1-10 values, where 1 being the lowest latency 100 in the code, and 10 being 10 in the code, with default at 9.
basic2004
Posts: 118
Joined: Sun 08 Jan, 2017 5:59 pm

Re: [Solved] PCem v12 and Sound Lag

Postby basic2004 » Tue 06 Jun, 2017 6:40 pm

James-F wrote:People use various machines to run PCem, so maybe make this buffer length user configurable so the user can find the right value for his system.
In DOSBox this value called "blocksize" and is configurable by the user.

Maybe make this division value an integer (48000/X) and let the user adjust it from 10 to 100 in the configuration menu, where 100 is the lowest latency but requires the most powerful machine.
You can obviously reverse it in the UI to 1-10 values, where 1 being the lowest latency 100 in the code, and 10 being 10 in the code, with default at 9.

I agree, sound buffer should decide by user who needs low-latency.

Is this buffer uses milisecond?
I think 48000/50 as 960ms, 48000/20 as 2400ms.
and I want adjust sample rate, 44100Hz, 48000Hz and so on... if possible.

I use an USB DAC. Meridian Explorer.
This device can reduce latency, less 50ms in WASAPI exclusive.
SarahWalker
Site Admin
Posts: 1333
Joined: Thu 24 Apr, 2014 4:18 pm

Re: [Solved] PCem v12 and Sound Lag

Postby SarahWalker » Tue 06 Jun, 2017 8:36 pm

basic2004 wrote:Is this buffer uses milisecond?
I think 48000/50 as 960ms, 48000/20 as 2400ms.

No, it's measured in samples. 48000/50 is 20ms, 48000/20 is 50ms.

and I want adjust sample rate, 44100Hz, 48000Hz and so on... if possible.

Somewhat pointless - the odds of your DAC having a sample rate that isn't a multiple of 48 kHz is basically nil.
User avatar
leilei
Posts: 436
Joined: Fri 25 Apr, 2014 4:47 pm

Re: [Solved] PCem v12 and Sound Lag

Postby leilei » Tue 06 Jun, 2017 10:48 pm

OpenAL's locked to 48khz anyhow, or at least I couldn't ever find a way to change from it.
Malik
Posts: 17
Joined: Sat 20 May, 2017 2:43 am

Re: [Solved] PCem v12 and Sound Lag

Postby Malik » Wed 07 Jun, 2017 12:05 am

basic2004 wrote:
James-F wrote:People use various machines to run PCem, so maybe make this buffer length user configurable so the user can find the right value for his system.
In DOSBox this value called "blocksize" and is configurable by the user.

Maybe make this division value an integer (48000/X) and let the user adjust it from 10 to 100 in the configuration menu, where 100 is the lowest latency but requires the most powerful machine.
You can obviously reverse it in the UI to 1-10 values, where 1 being the lowest latency 100 in the code, and 10 being 10 in the code, with default at 9.

I agree, sound buffer should decide by user who needs low-latency.


True. We all use different machines. And yes, this will be a useful solution.
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Solved] PCem v12 and Sound Lag

Postby James-F » Wed 07 Jun, 2017 4:19 am

There is a problem with the openAL32.dll (old) that comes with PCem V12.
Although it has no stereo separation issue that the newer openAL32.dll has, but it truncates frequency response above 10kHz.
Moreover, the old openAL32.dll has major aliasing issue I can hear and see when playing 440.wav test tone.

Other PCem builds don't have openAL32.dll related issues at all, stereo, frequency response, and aliasing are no issues there.
Moreover, the 'other' build don't require openAL32.dll at all.

Battler, what is your build has instead openAL32.dll?

Blue is openAL32.dll that comes with V12, Red is newer openAL32.dll from MinGW (has stereo bug).
Image
Malik
Posts: 17
Joined: Sat 20 May, 2017 2:43 am

Re: [Partially-Solved] PCem v12 and Sound Lag

Postby Malik » Wed 07 Jun, 2017 4:35 am

What about the official openAL32 from it's own website?

I think Battler's build is using the openAL installed in the Windows system directory??
User avatar
James-F
Posts: 69
Joined: Tue 30 May, 2017 10:26 am

Re: [Partially-Solved] PCem v12 and Sound Lag

Postby James-F » Wed 07 Jun, 2017 4:39 am

There is no dependency on openAL32.dll whatsoever in Battlers build, hence bug free audio operation.
The problem that each openAL32.dll version has its own ugly bugs, it's time to remove dependency on it completely from PCem.
Last edited by James-F on Wed 07 Jun, 2017 4:40 am, edited 1 time in total.
Malik
Posts: 17
Joined: Sat 20 May, 2017 2:43 am

Re: [Partially-Solved] PCem v12 and Sound Lag

Postby Malik » Wed 07 Jun, 2017 4:40 am

James-F wrote:There is no dependency on openAL32.dll whatsoever in Battlers build, hence bug free audio operation.


I see.
Battler
Posts: 793
Joined: Sun 06 Jul, 2014 7:05 pm

Re: [Partially-Solved] PCem v12 and Sound Lag

Postby Battler » Wed 07 Jun, 2017 2:55 pm

James-F wrote:Battler, what is your build has instead openAL32.dll?

That would be libopenal-1.dll which is openAL32.dll under another name, because GCC 6.x decided to rename the OpenAL DLL. It is also newer.

There is no dependency on openAL32.dll whatsoever in Battlers build, hence bug free audio operation.
The problem that each openAL32.dll version has its own ugly bugs, it's time to remove dependency on it completely from PCem.

The dependency is still there, the DLL is just named differently and is probably far newer.

Return to “General”

Who is online

Users browsing this forum: No registered users and 1 guest