Audio Lag with PCem 11 (was able to repro in latest source)

[Mr.Nacho]

Hello,

First time poster. Many thanks for all the work done on PCem. Quite an amazing project. Looking forward to the next official release!

I'm relatively new to PCem, as such, not sure if this has been reported before (or if I'm in the proper forum) -- please let me know if that's the case.


Sound FX Lag Issue:
I noticed while playing Doom (shareware 1.9) that all sound FXs seem to lag by half a second (guesstimate). I compared with the game running in DosBox (latest SVN) as well as on real hardware (IBM Personal Computer 330 -- P133 with 16MB RAM). DosBox *might* lag by a few micro seconds, but it's not as bad as on PCem.

PCem always runs at 100%. Tried different motherboard / CPU configurations (486, P75, P133) with different sound cards (with appropriate SB drivers). Tried inside DOS 6.22 and MS-DOS Mode (Windows 98 SE).


Host Machine:
My host machine is running Windows 10 on a i7 4770K CPU.


Repro Steps:
1- Simply launch Doom (shareware 1.9) and navigate up and down in the main menu. Notice the graphics update immediately upon user input but the sound updates a little later. The same occurs in-game when pressing shooting.

2- I also experienced the same lag in the Doom (shareware 1.9) setup utility (although the sound output is actually PC Speaker beeps). To repro, simply run setup and navigate up and down and press Enter / ESC to hear the various beeps (high pitch, low pitch). Notice the lag.

3- I also played around with the pro_org.exe program that comes with the SBPro install disks. The lag also happens in there when playing the organ, maybe even more so noticeable.

4- Lastly, I tried running Doom with only PC Speakers as Sound FX. The lag is still there.


Latest code still seems affected:
Following a guide on the forum, I managed to compile the latest code from bitbucket (up until commit # 4e95feb). Still able to reproduce the lag. Might be good if someone could confirm that they were able to repro as well (in PCem 11 and latest).

Let me know if you want to see a side-by-side video with the real hardware vs PCem vs DosBox.

Thanks,
Mr.Nacho

[szadycbr]

Your Guesstimate is almost ok. but my gues is about 0.3 sec on p75, but yes there is small lag on doom. But remember one thing, You can not compare PCem to dosbox , by any means, Dosbox barely emulates any hardware, and when it does it makes shortcuts by simulating some behaviour, it was designed to run dos programs , and not to emulate real hardware. But Good Catch, the lag can be noticed on menu and gun shots. Heretic has the same issue, i think it is the same engine anyway. Dont have Hexen to check, but can assume it will have same issue.

[UPerschke]

Can you post your config for both latest and V11 please? There seems to be an odd correlation with emulated CPU speed. The higher it is the worse it gets. I set mine to 486SX20 and no delay with speaker nor SB, regardless if recompiler or interpreter. I did get noticayble delays with 486DX2/66, 486DX4/100 and over 0.5sec with P90.

Side note: Tried with VMWare player (binary translation, no VT-x) and no delay at all. Tests with Qemu and Bochs in progress. Mainly to exclude inherent behaviour.

[Mr.Nacho]

Sure, here are the different configurations I tried with PCemV11.

Another thing that I noticed (could be related or not) is if I press and hold the Down key while in the menu, it doesn't seem to cycle through the menu items as fast as on real hardware (or in DosBox). Might be something to investigate as well (keyboard handler perhaps, or could be related to the sound lag issue, or something else completely).

High-End 486 DX4 100:

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 0
model = 35
cpu_manufacturer = 0
cpu = 12
cpu_use_dynarec = 1
gfxcard = 9
video_speed = 2
sndcard = 6
cpu_speed = 10
has_fpu = 1
slow_video = 1
cache = 3
cga_composite = 0
disc_a = 
disc_b = 
mem_size = 16384
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 2
cdrom_path = 
vid_resize = 0
vid_api = 0
video_fullscreen_scale = 0
video_fullscreen_first = 1
hdc_sectors = 63
hdc_heads = 16
hdc_cylinders = 2048
hdc_fn = C:\PCemV11Win\1994_486DX4_100Mhz\C_HDD_486_100Mhz_16MB_SBAWE32_MSDOS_622_FAT16_1008MB.img
hdd_sectors = 0
hdd_heads = 0
hdd_cylinders = 0
hdd_fn = 
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn = 
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn = 
drive_a_type = 5
drive_b_type = 0

Mid-End P133:

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 0
model = 38
cpu_manufacturer = 0
cpu = 5
cpu_use_dynarec = 1
gfxcard = 9
video_speed = 4
sndcard = 7
cpu_speed = 16
has_fpu = 1
slow_video = 1
cache = 4
cga_composite = 0
disc_a = 
disc_b = 
mem_size = 65536
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 1
cdrom_path = 
vid_resize = 0
vid_api = 1
video_fullscreen_scale = 3
video_fullscreen_first = 0
hdc_sectors = 63
hdc_heads = 16
hdc_cylinders = 1024
hdc_fn = C:\PCemV11Win\1995_Pentium_133Mhz\C_HDD_Pentium_133Mhz_64MB_SB16_WIN95_FAT32_508MB.img
hdd_sectors = 0
hdd_heads = 0
hdd_cylinders = 0
hdd_fn = 
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn = 
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn = 
drive_a_type = 7
drive_b_type = 0

High-End P233 MMX:

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 1
model = 38
cpu_manufacturer = 0
cpu = 11
cpu_use_dynarec = 1
gfxcard = 17
video_speed = 5
sndcard = 8
cpu_speed = 24
has_fpu = 1
slow_video = 1
cache = 3
cga_composite = 0
disc_a = 
disc_b = 
mem_size = 262144
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 1
cdrom_path = 
vid_resize = 0
vid_api = 1
video_fullscreen_scale = 0
video_fullscreen_first = 1
hdc_sectors = 63
hdc_heads = 16
hdc_cylinders = 4096
hdc_fn = C:\PCemV11Win\1997_Pentium_233Mhz\C_HDD_PentiumMMX_233Mhz_256MB_SBAWE32_WIN98_FAT32_2016MB.img
hdd_sectors = 0
hdd_heads = 0
hdd_cylinders = 0
hdd_fn = 
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn = 
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn = 
drive_a_type = 7
drive_b_type = 0

Here's the config file I used with the latest source (Mid-End P133):

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 0
model = 40
cpu_manufacturer = 0
cpu = 5
cpu_use_dynarec = 1
gfxcard = 4
video_speed = 5
sndcard = 7
cpu_speed = 16
has_fpu = 1
slow_video = 1
cache = 4
cga_composite = 0
disc_a = 
disc_b = 
mem_size = 65536
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 1
cdrom_path = 
vid_resize = 0
vid_api = 1
video_fullscreen_scale = 3
video_fullscreen_first = 0
hdc_sectors = 63
hdc_heads = 16
hdc_cylinders = 1024
hdc_fn = C:\PCemV11Win\1995_Pentium_133Mhz\C_HDD_Pentium_133Mhz_64MB_SB16_WIN95_FAT32_508MB.img
hdd_sectors = 0
hdd_heads = 0
hdd_cylinders = 0
hdd_fn = 
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn = 
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn = 
drive_a_type = 7
drive_b_type = 0
cpu_waitstates = 0
window_w = 0
window_h = 0
window_x = 0
window_y = 0
window_remember = 0
joystick_type = 0
mouse_type = 0
enable_sync = 1

[Joysticks]
joystick_0_nr = 0
joystick_1_nr = 0

[UPerschke]

Those show delays here as well. CPU always at 100%. But: Same as before, slower CPU = less delay.
468SX16 --> None or at least close enough to none to notice any.
Video speed seems to make a difference, but not sure without some screen + sound recordings.

Tested with V11, debug build, release build and profiled release build (all from latest).

Qemu, Bochs, Parallels Deskop & Virtual Box: No satisfying results at all. Their SB16 emulation is too horrible.
My 486SX16 config for builds from latest:

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 0
model = 36
cpu_manufacturer = 0
cpu = 0
cpu_use_dynarec = 1
cpu_waitstates = 0
gfxcard = 9
video_speed = 5
sndcard = 7
cpu_speed = 0
has_fpu = 0

Have you tried to lower CPU speed?

[omarsis81]

He stated in his first post that "PCem always runs at 100%."

[Mr.Nacho]

Unfortunately, I haven't noticed any improvements by using a slower CPU. The lag seems about the same. Even with the Acer 386SX25/N.

With that being said, while testing different motherboard configurations, the lag even seems to occur when the BIOS is counting memory at startup. The numbers are done incrementing but you still hear some sound for the same amount of delay.

[Mr.Nacho]

To follow-up on my last reply, I did a few more tests. Nothing too fancy.

I simply hard reset machines and check if the BIOS memory count test and sound ticks are in-sync. I don't even proceed to loading an OS.

I tried with CGA and VGA video cards to see if it made a difference.

I also tried with different cache sizes.

So far, none of these made a difference.

I tried to focus on two things:
1- Notice sound tick lag at each incremental memory count.
2- Notice sound tick lag at the very end when the memory count is done.

In my opinion, the lag is more apparent at the very end simply because I feel that during counting, the sound tick from the previous memory increment is played almost perfectly off-sync by one memory count step (not sure if that makes any sense).

The lower the MHz, the easier you can spot the sound sync issue. The higher the MHz, the harder the problem is to notice (but it's still there).

Here are the different configurations I tested (with VGA/CGA and various cache sizes).
- AMI 286 Clone (286/6) - 2MB RAM
- DELL System 200 (286/12) - 2MB RAM
- Acer 386SX25/N - 2MB RAM
- AMI 386 Clone (i386SX/16) - 8MB RAM

To help illustrate the issue, here are a few youtube reference videos to show how the sound syncs up on real hardware.
- https://www.youtube.com/watch?v=ptYHlQvMoMY
- https://www.youtube.com/watch?v=ew797UATHsk
- https://www.youtube.com/watch?v=HvLEudQuaMA (kind of hard to see because of crystal display refresh)
- https://youtu.be/sy4wJNAfhrQ?t=23s

Could it maybe be related to how sound is initialized or played back? Audio library lag?

Might be relevant, at some point during my tests, the sound ticks stopped playing completely during memory count. I had to close PCem (instead of hard resetting) for sound ticks during memory count to be heard again. Unfortunately, I wasn't able to repro afterwards.

[Battler]

I think this is because the BIOS uses the PC speaker to plays those sound ticks, and that's a bit hit and miss in PCem right now, seems the faster the emulated CPU, the shorter the speaker timings, which makes a lot of things go wrong. On later Award boards (486 and Pentium), the POST OK beep that should be decently long, can get way too short, to almost inaudible depending on how fast the emulated CPU is.

[SarahWalker]

I've reduced the size of the main sound buffer in rev 627, hopefully this should improve things a bit.

[szadycbr]

I have just checked doom with 627 and i did run on p75, if there is any lag now, i cant really notice, it is way better.
Everybody, lets check, you will see , i think the lag on doom is gone.
BTW to anyone, do you mind to tell me which line in which file is responsible for sound buffer length?

[omarsis81]

I have just checked doom with 627 and i did run on p75, if there is any lag now, i cant really notice, it is way better.
Everybody, lets check, you will see , i think the lag on doom is gone.
BTW to anyone, do you mind to tell me which line in which file is responsible for sound buffer length?

You can track all updates here https://bitbucket.org/pcem_emulator/pcem/commits/all

The line you are asking for is 451 from src/ibm.h

-#define SOUNDBUFLEN (48000/10)
+#define SOUNDBUFLEN (48000/40)

[Mr.Nacho]

I agree, the lag is much much less apparent in all the cases mentioned above. Thanks SarahWalker!

Maybe my mind is playing tricks on me, but I feel _sometimes_ the music skips simply by running around the first level (Doom shareware). It happened before rev 627 but I feel it might happen more now. Could that be a side-effect (buffer underruns)?

EDIT:
Unfortunately, I noticed another side effect with rev 627. This time it presents itself as a very minor but easy to hear "fluttering" effect on audio playback. It occurs in Windows 98 SE when it boots up (if you have the default startup sound).

To repro manually in Win98SE:
1- Click "Start" ->"Run..."
2- Enter "mplayer2" then click OK
3- Click "File" -> "Open..."
4- Locate "C:\WINDOWS\MEDIA\The Microsoft Sounds.wav" and click OK
5- WAV file should start playing (press play if it doesn't)

Notice that before rev 627, playback output is consistent. With rev 627, playback has a fluttering waving output (more noticeable on high frequencies).

Configuration:

Code: Select all

gameblaster = 0
gus = 0
ssi2001 = 0
voodoo = 1
model = 40
cpu_manufacturer = 0
cpu = 5
cpu_use_dynarec = 1
gfxcard = 19
video_speed = 5
sndcard = 8
cpu_speed = 16
has_fpu = 1
slow_video = 1
cache = 3
cga_composite = 0
disc_a = 
disc_b = 
mem_size = 131072
cdrom_drive = 0
cdrom_enabled = 0
cdrom_channel = 1
cdrom_path = 
vid_resize = 0
vid_api = 1
video_fullscreen_scale = 0
video_fullscreen_first = 1
hdc_sectors = 63
hdc_heads = 16
hdc_cylinders = 4096
hdc_fn = C:\PCemV11Win\1995_Pentium_133Mhz\C_HDD_Pentium_133Mhz_128MB_SBAWE32_WIN98_FAT32_2016MB.img
hdd_sectors = 0
hdd_heads = 0
hdd_cylinders = 0
hdd_fn = 
hde_sectors = 0
hde_heads = 0
hde_cylinders = 0
hde_fn = 
hdf_sectors = 0
hdf_heads = 0
hdf_cylinders = 0
hdf_fn = 
drive_a_type = 7
drive_b_type = 0
cpu_waitstates = 0
window_w = 0
window_h = 0
window_x = 0
window_y = 0
window_remember = 0
joystick_type = 0
mouse_type = 0
enable_sync = 1

[Joysticks]
joystick_0_nr = 0
joystick_1_nr = 0

[szadycbr]

Yeah, its there, i was wrong assuming thats just cos of not enugh fast host CPU cos i was talking about skipping issue, i didnt listen properly. Leilei is right. it occurs also at 98-101 %

[leilei]

I'm getting fluttering too and that's even with execution hovering in the 98-101%

[szadycbr]

ok, i did play this morning a bit, all test have been done on p75 making sure it is always at 100% and sb16 if it matters on win98.
i did build :
#define SOUNDBUFLEN (48000/40) Sarah version
#define SOUNDBUFLEN (48000/0) error divide by zero , or something like that
#define SOUNDBUFLEN (48000/1) wooow, lag 5 seconds or so (plays even after exit application)
#define SOUNDBUFLEN (48000/20) Fluttering
#define SOUNDBUFLEN (44000/20) fluttering
#define SOUNDBUFLEN (40000/20) fluttering
#define SOUNDBUFLEN (36000/40) fluttering
#define SOUNDBUFLEN (36000/20) fluttering
#define SOUNDBUFLEN (32000/40) some flutering
#define SOUNDBUFLEN (32000/20) tadaa! appears not to do any flattering on windows 98 boot sound. played many Times in control panel.
i donk know but i assume thats 32khz and some quality is lost , but honestely i dont feel much, and even my med.-high quality head phones do only up to 36khz
any way i dont really know , and i m tired compiling, so thats my tiny input, maybe it will help Sarah.
each time i changed that 48000 thing, fluttering was different the lower the less i think but always different.
for now i use #define SOUNDBUFLEN (32000/20) version.

[Battler]

i donk know but i assume thats 32khz and some quality is lost , but honestely i dont feel much, and even my med.-high quality head phones do only up to 36khz

No, the quality is still normal, you just reduced the buffer size.

[SarahWalker]

If you haven't, can you update to rev 628? 627 had some bugs.

[szadycbr]

Can anyone tell me how to download 628? i do always use last link on bitbucket page, i press download, then i do download that repository wchich says 2.5 megs but it really is 1 Mb and something, i download this: https://bitbucket.org/pcem_emulator/pcem/downloads is it the thing? and is this repository always automatically updated? cos if yes then i downloaded this version right now, and fluttering didnt change. Try 32000/20 , you will see difference.
and thank You battler, can you tell me what it really is the 48000 and the 40 at the end? i know you said buffer length, but 48000 of what? kb? ms.? divided by 40? or what? it would be nice to know, and if it is buffer lenght as you said, then i will try to decrease, it might be perfect when lower i will see but 32000/20 is quite good.

[szadycbr]

when i was writting above post , it took me a while, and PCem was on waiting, after i posted i go back to PCem to see , did i hear that right, and flutterig was gone, i thought that i wrote some rubbish and it plays the sound fine, but after restart it flutter again. maybe thats still 627?

[Battler]

-szadycbr: Words (ie. 16-bit units). PCem's sound buffer user to be 48000 words, ie. 96000 bytes. Sarah reduced it to 1/40 of that, so 1200 words, or 2400 bytes. You changed it to 32000/20 = 1600 words, or 3200 bytes.

[szadycbr]

Battler thank You very much, no i know, but i did now 20000/20 and fluttering was back, and on 32000/20 is not, and on all other combinations i did going higher than 32000 fluttering is there, i dont understand this at all, does it need right balance? he he, i dont get it, i thought on 20000/20 it might start skipping but insted it was fluttering, but a bit more frequentely.

[Battler]

That's because 20000/20 = 1000 words, or 2000 bytes, less than the 48000/40 you reduced from (48000/40 is equivalent to 24000/20). Probably it flutters when the buffer is too small. Also, rather than looking at both numbers (20000 and 20) separately, look at them together - 20000/20 means 20000 divided by 20. If you increase the number before /, the result of the division increases, meaning a bigger buffer, but if you increase the number after /, the result of the division decreases, meaning a smaller buffer.

[szadycbr]

Thank You Battler now i do know a bit more , why this numbers are there and how can i play with it, thank You.

[szadycbr]

I have made myself the last repo with P50 and buffer 32000/20 and it works like a charm for doom and heretic, no lag , no fluttering. even when i run P75 on i5 2140m often PCem drop to 75-80 % during loading/file handling, P50 works 100% all the time!!!

[leilei]

It would probably help to name host audio chipsets used with their default format chosen. In my case it's a Realtek ALC892 in 48khz 24bit

[Mr.Nacho]

I compiled latest (up to commit 1224567) and I'm still experiencing the fluttering in Windows 98 while playing the WAV file.

I also have a Realtek ALC892.

[szadycbr]

Guys, before this issue PCem had buffer 4800 words (9600 bytes) and the lag was noticable, Sarah reduced that qiute a bit , to 1200 words (2400 bytes) and the lag was gone but fluttering appear out of nowhere, i did play with something i have no clue about and i make 1600 words (3200bytes) so slightly bigger than Sarah buffer, and fluttering isnt there, but it appears that the lag might be slightly bigeer than on 1200 words but not really noticeable i would say.
And can someone tell me why #define SOUNDBUFLEN (48000/40) is used in the script? i did #define SOUNDBUFLEN (4800) also (1600),(1200) without making tens of thousands divided by 40 or so, and it compile the same way , works the same way, so why things are complicated?
Battler explained to me a lot about this, but not why to divide. is it necessary?

[Battler]

- szadycbr: Originally it was #define SOUNDBUFLEN 48000, using a 48000 word (96000 bytes) buffer, then to fix the lag, Sarah simply added the /40 there to reduce the buffer to 1/40 of its size without having to do the actual calculation and get the new buffer size to write there.

By the way, did you try a buffer size of 1400? It's in between 1600 and 1200.

[szadycbr]

no i didnt try 1400, will check later, but what is the thing with dividing? #define SOUNDBUFLEN (4800) that line compile just fine, so what is it?