captainys / TOWNSEMU

FM Towns Emulator "Tsugaru"
BSD 3-Clause "New" or "Revised" License
251 stars 21 forks source link

Scratchy / stuttery audio #76

Open prietveld opened 1 year ago

prietveld commented 1 year ago

I have been playing around with a ton of FM Towns images and Tsugaru settings, and while nearly everything plays perfectly fine with the odd issue here or there, almost all games have pretty bad / scratchy / stuttering sound for me.

CD audio plays back fine, but MIDI or digital audio is pretty poor. Could this be a host performance issue? I have a 1st gen (Nehalem) i7 @3.4GHz and am running Windows 10x64. Game performance seems fine otherwise.

I have tried emulating specific models, lowering or raising the emulated CPU speed, enabling and disabling FPU emulation and enabling and disabling 'Catch Up Real Time'. None of these have had a noticeable effect so far.

captainys commented 1 year ago

You may be experiencing the same situation as my PC. Turned out, a Win32 function, PeekMessage was taking more than 20 milliseconds and made it impossible for Tsugaru to fill the next segment. For this problem I don't have a solution. Closing Web browsers made it less irritating.

Another problem was although Direct Sound 8 document tells that write cursor is ahead of play cursor by 15 milliseconds, it was 20 milliseconds for my driver. I don't know if it is common or not. Tsugaru was supposed to have 5 milliseconds buffer to fill the next segment, but since it was not working as described on the document, Tsugaru had almost zero buffer.

I have added 10 milliseconds extra ring-buffer size so that Tsugaru has at least 10 milliseconds to fill the next segment even when the driver is not working as described in the Microsoft's official document. This eases the irritating noise a little bit.

If you can compile, please try the latest source, and let me know if it makes noise better.

prietveld commented 1 year ago

Thanks for your reply! I didn't have a browser (or much else) running in the background, but perhaps the buffer increase helps. Can we discount it simply being lack of CPU horsepower? First gen i7s might lack certain instruction sets of the later models? Anyway, I'd like to try it, but I don't have the environment nor the ready-to-go knowledge to compile from source. I'll give the next release a try as soon as it's out!

bcc2528 commented 1 year ago

I don't think the instruction set is relevant. Simply CPU performance potential. First generation Intel Core CPU have only about half the single threaded performance compared to the latest generation CPU, even if they were clocked identically.

prietveld commented 1 month ago

Wanted to bump this and mention that since the version that added 'maximum double buffering' sound stuttering has been worse than prior versions for me, either with that option checked or unchecked. Basically almost no titles run without sound stuttering for me anymore, and that now includes CD redbook audio, which was fine before this change. Lower CPU MHz settings improve the situation a bit, but it never gets to a point where it's smooth.

If this is just my 3.4 GHz Nehalem i7 not cutting it for running the emulation feel free to close this issue, but as graphics performance runs perfectly fine it seems like something else might be going on here.

bcc2528 commented 1 month ago

3.4 GHz Nehalem i7 not cutting it for running the emulation

Without a doubt, the first generation Core i7 is not suitable for running the Tsugaru emulator. Again, even at the same frequency, that is less than half the single-threaded performance of the latest Core i-series CPUs. The maximum FREQ setting (VM CPU MHz) that can be reached in time for processing on that CPU is probably 8. For example, in my own PC environment, the upper limit at which it could run without any stutters was FREQ: 66 on a desktop machine with a Core i5 12600 (TB: 4.8GHZ), and FREQ: 20 on a laptop with a Core i5 8250U (TB: 3.4GHz).

prietveld commented 1 month ago

Ok, thanks for confirming. I'll try to see what I can get running acceptably at 8MHz. This can be closed then, as far as I'm concerned. Hoping possibly future optimizations might improve this somewhat.

Side note that a SFF i5 7500T 'low power' (but more recent) system I have does indeed run the emulation a bit better.