Audio pitch problems?

[cools]

Perfect audio: groovymame64 rtype -effect none
Messy audio (pitch rising and falling): groovymame64 rtype -effect scanlines

Logs attached. I don't see any difference between them.

[Calamity]

I'd say the -effect scanlines feature is very resource hungry on high resolutions, so it must be causing speed drops. But your logs show the speed is 100%, which apparently is fine but because it's an average it could be masking the slowdowns.

As a note, with cards older than the HD 6xxx I've always had troubles using super resolutions above 240p-288p

[cools]

This was working perfectly on the same hardware in the past. If I try bgfx instead it's fine, but I get static tearing.

Watching the in-game speed % it doesn't wobble at all, and it doesn't feeling like the emulation is slowing down either. I'm not convinced it's resource related but I'll try with non-super resolutions when I get a chance.

You keep trying to convince me to upgrade my cards but so far I've genuinely found no difference from the XFX 4350's I started with - those worked perfectly with super resolutions and fake scanlines with the older CRT_Emudriver. Every time I upgrade it's a pain grabbing a PC monitor and doing all the cable swapping - I'm sure you secretly have 200 eBay accounts pushing fanless old Radeons

I'll play around some more and see what I can establish. Normal resolutions, and older versions of GM.

[Calamity]

 

Try to figure out the pain when some random user complains about an issue with an old HD 4xxx and I have to open my test box, plug in the the old 4350, reinstall drivers, loose all configurations, just to confirm it's a legit bug (which very often it's not). But yeah, you gave me an idea with the ebay thing 

Just in case, in version 17i I made a change in the audio sync part that was breaking save states, so I'd start by confirming 17h was free of the issue.

[cools]

Will do. Got a 6450 on the way from one of your shill accounts

[cools]

Using a lower super resolution sorted it, so you were right about it being resource (or card) led. It's still bugging me that it was working flawlessly before. I'm going to try the 6450 soon and see what happens.

I didn't know "effect" was a purely software option. Wondering if there's a BGFX or HLSL method that can do the equivalent on the GPU.

[cools]

More! I've been having the same problem on another machine, playing games that I know have worked perfectly in the past. Normal 15k monitor.

I dropped from super resolutions to native. No luck.

I think I've almost pinned it down. 4 logs attached for Fantasy Zone
1) My normal execution, refresh_dont_care 0. Desktop 728x576 52hz. Bent sound
2) refresh_dont_care 1. Desktop 728x 576 52hz. Bent sound
3) refresh_dont_care 0. Desktop 320x240 60hz. Bent sound
4) refresh_dont_care 1. Desktop 320x240 60hz. Perfect sound

Fantasy Zone is not performance heavy, I get > 1000% benching it.

Code: [Select]

C:\MAME>mame64 fantzone -bench 30

SwitchRes: [fantzone] (1) horizontal (320x224@60.000000)->(320x240@60.000000)
Frame delay/percentage: 8/25.00% 9/75.00%
Average speed: 1016.87% (29 seconds)
Other games don't exhibit the same behaviour with the desktop resolution set to 768x576, but they do get saved with refresh_dont_care 1 (R-Type Leo for example warbles like crazy with refresh_dont_care 0)

All that said I'm not entirely convinced I'm right. SwitchRes likes to select either 320x240 or 640x240 for Fantasy Zone, and repeated testing - some runs it warbles, others it's fine. If I run it in a window, no matter what the desktop resolution is the sound is flawless (albeit slow or fast depending on the refresh rate)

My next port of call if this doesn't ring any bells as a problem is to start swapping graphics cards around.

[Calamity]

Refresh_dont_care shouldn't make any difference. The fact it *does*, is because it allows picking the desktop's resolution, which normally is avoided for being read-only. And because it's read-only, the timings update doesn't work, and this is what seems to be "fixing" it. So the issue is with the timings update.

I'd need you to check something before considering other stuff. Please check if the same issue happens with Switchres 0.017j (previous GM version). It seems that you already did, considering your first post, but I'm not sure if it's the same issue (in case you're sure it is, let me know, that's what I mean). I just want to discard it is due to the change in pixel clock done in 17k (I'm pretty sure it's not that, but just in case).

[cools]

I did go back and check GM 182 (SwitchRes 0.16 final), and it exhibits the same behaviour. I've been hearing the same warbling across multiple machines (that I've had for years without previous problems), and the only thing I know for sure is that the cards are 5450s rather than 4350s with the appropriate driver change.

In case this is significant - MAME reports average speed of 99.9~ when the sound is fine. Under 99.9 or over 100.1 it's warbling. I can't get it to lock at 100% at all

[Calamity]

Sound should be solid regardless the speed. Anyway it's normal that you can't lock it at 100.00%, due to dotclock granularity. The thing you can try is to grab the default 320x240 modeline from Arcade OSD, paste it in fantzone.ini and run the game. That should cause the same effect as the use of refresh_dont_care. Not meaning this is a solution, just a confirmation test.

Aside from the 4350 to 5450 change, do you think it could be that now you're using PortAudio while probably before you were using DirectSound?

I'm compiling a special GM build for testing, it'll be ready in a while.

[cools]

Tried disabling portaudio and it made no difference so I left it on for the logs.

I'll have a go again tonight with the .ini.

[Calamity]

Try this build: https://drive.google.com/open?id=1ejvXCZATjAQ0i8mvItwHpHct_yBBbqDT

(it uses a different system timer)

[cools]

Afraid not. First run I was excited because it worked, then I paused the game, unpaused and it was bad again.

I've tried all sorts this evening including fresh ini files (and discovering that using portaudio means you can disable the windows audio services and still have sound ). I had one boot cycle where it was perfect 15 times in a row, but that seems to have just been luck.

I've been watching the in game FPS % counter. When audio is fine it's locked at 100% for the duration, otherwise it is cycling 98-100-102-100-98-100-102.

If I intentionally frameskip using F9, the counter still continues to cycle (along with the audio) but with a higher %.

I don't like the random nature. I'm testing literally just launching MAME, and within moments if the counter starts bouncing I quit, restart and try again.

Haven't tried switching GPU yet. I'm convinced it's hardware or Windows doing something weird, but MAME exposes the weirdness. Quite what it is though... I only have 9 services running!

[Paradroid]

I only have 9 services running!

Lean and mean!

[Paradroid]

I'm convinced it's hardware or Windows doing something weird, but MAME exposes the weirdness.

Perhaps give this this a read? DPC Latency Checker is really useful when you have audio issues related to poor driver performance. Long shot... but it has helped me in the past.

[Calamity]

I understand your tests were done with the special build I posted.

When audio is fine it's locked at 100% for the duration, otherwise it is cycling 98-100-102-100-98-100-102.

That's is the key. And I'm almost sure you didn't notice any scroll stutter or visible performance drop on the video, did you?

That would point to wrong time measurement by MAME. I've seen it before. I believe this started to happen when the core was "modernized" to use std::chrono instead of directly handing Windows timing API calls.

Back then we had to change std::chrono to use the "steady clock" instead of the "high resolution clock", otherwise it would cause the exact issue you're seeing when running on XP. Windows 7 seemed to work fine with both. The build I posted yesterday uses the high resolution clock instead, just like baseline MAME.

This bogus speed information wouldn't be an issue if it wasn't because GroovyMAME uses it as feedback for the audio sync feature, causing it to wobble.

In the old days the speed information was so stable with syncrefresh on that I decided to remove "audio sync" as a separate option. Maybe it's time to readd this option, although I hate doing it.

My guess is that it's the interaction between the actual pixelclock and the granularity of the system clock what's probably causing the issue.

You may try changing your system's clock source. Check the posts by Dr.Venom here.

[cools]

Yes, with the special build (as well as standard just as comparision).

No stutter or otherwise, if I did I'd be looking at the machine performance.

Thanks for the link to the thread, I was thinking it had to be something to do with my machines clock but couldn't find the detail on how to change it again - was scouring the Latency thread at midnight. I'll give that a go tonight!

[cools]

I'm convinced it's hardware or Windows doing something weird, but MAME exposes the weirdness.

Perhaps give this this a read? DPC Latency Checker is really useful when you have audio issues related to poor driver performance. Long shot... but it has helped me in the past.

Checked, all fine. Fun to see that LatencyMon reports major issues if I have this forum open in Firefox in the background.

I understand your tests were done with the special build I posted.

When audio is fine it's locked at 100% for the duration, otherwise it is cycling 98-100-102-100-98-100-102.

That's is the key. And I'm almost sure you didn't notice any scroll stutter or visible performance drop on the video, did you?

That would point to wrong time measurement by MAME. I've seen it before. I believe this started to happen when the core was "modernized" to use std::chrono instead of directly handing Windows timing API calls.

Back then we had to change std::chrono to use the "steady clock" instead of the "high resolution clock", otherwise it would cause the exact issue you're seeing when running on XP. Windows 7 seemed to work fine with both. The build I posted yesterday uses the high resolution clock instead, just like baseline MAME.

This bogus speed information wouldn't be an issue if it wasn't because GroovyMAME uses it as feedback for the audio sync feature, causing it to wobble.

In the old days the speed information was so stable with syncrefresh on that I decided to remove "audio sync" as a separate option. Maybe it's time to readd this option, although I hate doing it.

My guess is that it's the interaction between the actual pixelclock and the granularity of the system clock what's probably causing the issue.

You may try changing your system's clock source. Check the posts by Dr.Venom here.

(I can't disable HPET in the BIOS)
bcdedit /set useplatformclock true    WinTimerTester reports 14.31818 MHz
bcdedit /deletevalue useplatformclock  WinTimerTester reports 2.92239 MHz

Sadly neither make much difference. All the random behaviour reported already still happens. Long runs where it's perfect, long periods where I can't get any stability at all.

I've tried 181 Switchres 16alpha 6, same problem.

Going to try Catalyst 12.6 next as it's the last thing I can play about without messing with hardware.

[Calamity]

If the wrong timing theory is right,  -nosyncrefresh -waitvsync -nothrottle should bypass the issue.

[cools]

It's CRT Emudriver!

When I moved this PC I changed the cabling from a 5xBNC (with H+V sync 'joined') to a 4xBNC, and updated CRT Emudriver to allow for composite sync.

What I've only just noticed (I kept the old folder as a settings backup) is I jumped from Catalyst 12.6 to Crimson 16.2.1 non-GCN. It's been so long since I installed the driver I'd not realised I'd changed the core version entirely (user_modes.ini in that folder is dated August 2017).

Going to check the same thing on the other machine that had problems with effect scanlines and super resolutions when I get a chance.

[Calamity]

I wouldn't have thought of that but it makes sense that pixelclocks from one version to the other could vary. Maybe the old 5450 works better with the older Catalyst. It's better to use the newer version when possible for compatibility reasons (video playback, OpenGL, etc.).

[cools]

I'm wondering if modeline generation is different too, or if I've inadvertently changed a crt_range. My 52Hz "desktop" mode now seems to be 54Hz.

[Calamity]

Modeline generation is common to all versions. You have 54 Hz because probably you've chosen arcade_15 where previously you had generic_15. That allows a bit higher Hfreq.

[cools]

The tests (with Crimson) have definitely been with arcade_15 (it's in the logs). It's possible when restoring my old Catalyst ini files to the latest Catalyst that those are generic_15, but that would be backwards from what you've just said. 

[Calamity]

Well, who knows. Anyway that makes no difference.

Did you check on the other machine whether 16.2.1 was the culprit?

[cools]

Not yet, I should have time this evening.

[cools]

Yep, machine in opening post was running Crimson. I've switched to Catalyst and it's perfect with super resolutions and scanline effect. RType runs at 1200% with INS pressed, and no warbling sound. Same 5450.

[Calamity]

Ok, happy that you figured it out. There must be a problem with Crimson 16.2 handling your 5450. I've a 5450 on my test rig here and haven't had any similar problems with 16.2. However, I always had issues with the 5450 (Asus) with random flashes on high vertical super resolutions, which I have commented about before. But those happened on all versions versions of the drivers I tested.

[cools]

Mine are XFX

Still need to muster up the motivation to install and try the 6450 I have.