ALL 3.5 distros, DRASTIC cpu% loss FPS LOSS
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
#1410 ALL 3.5 distros, DRASTIC cpu% loss FPS LOSS
Bought an inexpensive laptop, (quad core, 8gb ram, win10home4bit), did a fresh install, and have all updates. EVERY version of WinVice when cmd emulation was implemented, fails on this laptop. The Emu runs fine, and everything works, but as soon as i launch x64 or x128 the FPS and CPU% go from 100% to 42% within 5seconds. ALL 3.5 distros behave the same. So I put 3.4 r3900 (one of the first cm d emulated options), and if i put it in, Warp Mode, it achieves ~70% CPU , and will hover there. Its am AMD processor, HP laptop. In short, drastic cpu usage immediately after launching either x128 or x64..... Thank You!
I apologize for not stating this right away, once Vice is launched, and i bring up Task Manager, my cpu usage is pegged to 99% in Windows. So im assuming Vice is putting an Un-godly load on my machine...
Please startup vice in a default config by going to the menu "setting" -> "restore default settings", press OK, and report on the CPU usage.
If it isn't high then, then start adding peripherals until you see the load change. Document the additions in order and post them here.
We need to replicate your problem to investigate it.
What do to mean by "cmd emulation"?
Can you try using the latest binaries at:
https://github.com/VICE-Team/svn-mirror/releases
And launch vice with the "-default" option. (you will need to do this with a command line) and let us know if the same issue happens.
Also, is your laptop plugged in or on battery? Please check your "power options" (in control panel to see what it is configure as.
No one noticed this problem? I started Vice and everything normal, after my work has done, closing it. If i open it again CPU Speed and FPS starting to gets lower and lower. Its like a joke. Using default settings.
Windows 10 20H2
intel Core i7 6700 - 3.4 Ghz
16 GByte RAM
Hi Bjorn, can you check if the problem still exists on the latest release from: https://github.com/VICE-Team/svn-mirror/releases ?
If it does, can you please share your config file so we can try to replicate the problem. (Or better, a command line that begins with -default that has the same problem)
Last edit: dqh 2021-03-26
Probably a problem with the DirectX driver. If you switch to wmm driver in the Audio/Sound settings speed is okay.
I remember the default (or even minimum) sound buffer was 100ms when I was involved in VICE development. The DX driver cannot handle the new default 26ms. Smallest buffer that works here with medium fragment size is 38ms. I can try to improve the DX driver but maybe just switch to wmm as default would help.
26ms seems to be working for most people, i've only heard a couple of reports of it not working. It's going to depend entirely on the hardware and drivers. wmm always operates with signifiant latency, so it doesn't make a good default when most people can run much faster. What we really need is a dx driver that automatically increases the buffer size when the device gets starved. We need this for all platforms really. Drop the fragment size thing and use a very small fragment size everywhere, and increase the buffer size by one fragment each time the device is starved, with a max of 100ms or so.
Andreas - are you also seeing host CPU usage when the dx buffer is too small?
OH, WAIT. I've been assuming host cpu problems. But on re-reading this are you just saying the emulator doesn't run at full speed? In which case yes, increase the audio buffer size. As a test, I would also expect the speed to be correct if you disable sound.
VICe timing is now based on the audio device. So if the audio device settings are not correct for the hardware & drivers, VICE will not run correctly.
Correct. Host cpu is not the problem, I'm running VICE on a Ryzon 4900H here. VICE just gets "too slow" and resyncs every some seconds with
so have you tried increasing the audio buffer size in the VICE settings?
Yes, increasing the buffer works as I indirectly said in earlier post.
But what is even better: I have a fix now for the DirectX driver that seems to make it work even with 26ms default buffer.
I haven't used svn for the last 6 years (only git) and the commands in the svn-instructions.txt seem not to work. How can I provide the patch? Just some few lines...
Last edit: Andreas Matthies 2021-04-05
Yes - I mistakenly thought I was addressing the OP rather than you. Many thanks for the patch for what looks like an ancient bug in our DirectSound code! Works well and makes total sense.
in the "vice" dir do "svn diff > foo.patch" (gotta check the svn-instructions...)
Here's the patch.
Commit message: "Use write cursor instead of play cursor to determine free buffer space".
BTW: So save some time after a clean checkout I did a "make x64sc" instead of "make" and ran into the following error. Probably some missing dependency in the Makefiles.
make[1]: *** No rule to make target '../src/datasette/libdatasette.a', needed by 'x64sc.exe'. Stop.
it's actually totally broken - and never worked correctly (not for a very long time at least)
Works if you use our cmake support though :)
i applied the patch here although i had no real issue on my older win 7 system.
still, i can go down to 10ms now, it was 22ms before. which is nice.
but i guess it needs more testing...
Whats the status here? Was that patch merged?
Yep, patch was merged