[Solved] Audio speedups and slowdowns with HLSL enabled

[oomek]

I'm experiencing periodical audio pitch modulation every 3-5 seconds if I enable HLSL filters.
I use a Freesync monitor with custom resolutions 1600x1080@72 for horizontal and 986x1080@72 for vertical games.
I use Portaudio as an output.
My CPU is i7 4770k and GPU Radeon R7 260X so I doubt the problem is caused by hardware.

[Calamity]

Hi oomek,

This is strange because you're not using -syncrefresh, so sound pitch should not be manipulated by GM. Try making your own build and log the m_speed member in video.c to monitor whether it is being updated somehow.

[oomek]

I cannot build at the moment. I do not have vmware installed yet as I’m in the process of reinstalling Windows.
This is even more strange. The audio pitch fluctuations are the worst on starting the game and the pitch stabilizes after 1-2 minutes of playing. What’s more it does not affect every game. Maybe its some rounding error of the framerate as I play games in their native refresh rates.

Here is a video I recorded showing it.

[intealls]

Have you tried baseline?

Just to rule that out.

[Calamity]

Also, press F11 to show the speed percentage during game play, to make sure it's not a speed issue (not meaning your pc isn't powerful enough, we've seen timing issues caused by many reasons).

[oomek]

Baseline is fine. And you are right. When the glitch happens the game speed goes to 99%,101% and back to 100%.
CPU usage hovers at 15%
GPU at 17%

[intealls]

Also, press F11 to show the speed percentage during game play, to make sure it's not a speed issue (not meaning your pc isn't powerful enough, we've seen timing issues caused by many reasons).

A sidenote, the speed seems to be much more stable when using syncrefresh compared to relying on the CPU timer (Windows 7, Z97, i3). Had issues with this a while back when experimenting with the ASIO stuff.

[oomek]

I can’t use syncrefresh as I run my games with freesync.
I found another thing that adds up to confusion. Normally with hlsl enabled the audio glitches happen for 1-2 minutes, BUT as soon as I press F11 they go away :/ when I press F11 immediately there is only one syncing glitch. Does it give any usefull clues to you?

[Calamity]

There's a specific patch in GM that changes the timing library used by mainline. This was done to avoid issues similar to yours under Windows XP. Maybe you should try building GM without that patch.

When you press F11 an overlay is added to the frame which may affect the rendering time, this probably is what modifies the overall behaviour.

[oomek]

I don’t know what patch you are talking about unfortunately. Is it a separate diff or a part of GM diff?
After further testing I realised that all I neeed to do is to press F11 twice and the audio glitches are gone. It seems like some variable used for timing calculations may be not initialised or calculated too early. It would explain that over time the average value builds up and stabilises the timing. Maybe F11 reinitialises it somehow, idk, I haven’t looked at the code yet. I’m posting from the phone.

[Calamity]

This is the diff that is applied by GM's patch and I'm suggesting you remove:

Code: [Select]

diff -Nru src/osd/osdcore.cpp src/osd/osdcore.cpp
--- src/osd/osdcore.cpp 2017-12-27 11:16:13.000000000 +0100
+++ src/osd/osdcore.cpp 2017-12-27 17:42:08.000000000 +0100
@@ -175,13 +175,19 @@
 }
 #endif
 
+#ifdef OSD_WINDOWS
+ typedef std::chrono::steady_clock s_clock;
+#else
+    typedef std::chrono::high_resolution_clock s_clock;
+#endif
+
 //============================================================
 //  osd_ticks
 //============================================================
 
 osd_ticks_t osd_ticks(void)
 {
- return std::chrono::high_resolution_clock::now().time_since_epoch().count();
+ return s_clock::now().time_since_epoch().count();
 }
 
 
@@ -191,7 +197,7 @@
 
 osd_ticks_t osd_ticks_per_second(void)
 {
- return std::chrono::high_resolution_clock::period::den / std::chrono::high_resolution_clock::period::num;
+ return s_clock::period::den / s_clock::period::num;
 }
 
 //============================================================
@@ -200,7 +206,7 @@
 
 void osd_sleep(osd_ticks_t duration)
 {
- std::this_thread::sleep_for(std::chrono::high_resolution_clock::duration(duration));
+ std::this_thread::sleep_for(s_clock::duration(duration));
 }

[Calamity]

There's another change applied to sound.cpp and sound.h cocerning sound management that makes GM different from baseline:

Code: [Select]

diff -Nru src/emu/sound.cpp src/emu/sound.cpp
--- src/emu/sound.cpp 2017-12-27 11:15:53.000000000 +0100
+++ src/emu/sound.cpp 2017-12-27 17:42:08.000000000 +0100
@@ -841,16 +841,13 @@
  machine.add_notifier(MACHINE_NOTIFY_RESUME, machine_notify_delegate(&sound_manager::resume, this));
  machine.add_notifier(MACHINE_NOTIFY_RESET, machine_notify_delegate(&sound_manager::reset, this));
  machine.add_notifier(MACHINE_NOTIFY_EXIT, machine_notify_delegate(&sound_manager::stop_recording, this));
+ machine.add_notifier(MACHINE_NOTIFY_FRAME, machine_notify_delegate(&sound_manager::update, this));
 
  // register global states
  machine.save().save_item(NAME(m_last_update));
 
  // set the starting attenuation
  set_attenuation(machine.options().volume());
-
- // start the periodic update flushing timer
- m_update_timer = machine.scheduler().timer_alloc(timer_expired_delegate(FUNC(sound_manager::update), this));
- m_update_timer->adjust(STREAMS_UPDATE_ATTOTIME, 0, STREAMS_UPDATE_ATTOTIME);
 }

@@ -1052,7 +1049,7 @@
 //  and send it to the OSD layer
 //-------------------------------------------------
 
-void sound_manager::update(void *ptr, int param)
+void sound_manager::update()
 {
  VPRINTF(("sound_update\n"));
 
...and

Code: [Select]

--- src/emu/sound.h 2017-12-27 11:15:53.000000000 +0100
+++ src/emu/sound.h 2017-12-27 17:42:08.000000000 +0100
@@ -223,7 +223,7 @@
  void config_load(config_type cfg_type, util::xml::data_node const *parentnode);
  void config_save(config_type cfg_type, util::xml::data_node *parentnode);
 
- void update(void *ptr = nullptr, s32 param = 0);
+ void update();
 
  // internal state
  running_machine &   m_machine;              // reference to our machine
Other than that, GM and baseline are the same thing.

[oomek]

Thanks Calamity, I'll try to look into it today. But guess what, after enabling triplebuffer the audio pitch does not fluctuate, but what is the most bizarre, It did not affect the input lag at all. I'm still getting 5-22ms with freesync on the thunderx test screen. Still trying to wrap my head around it 

[Calamity]

Thanks Calamity, I'll try to look into it today. But guess what, after enabling triplebuffer the audio pitch does not fluctuate, but what is the most bizarre, It did not affect the input lag at all. I'm still getting 5-22ms with freesync on the thunderx test screen. Still trying to wrap my head around it 

It could be that freesync is handling vsync on its own even with triplebuffer enabled, seems possible. I'd indeed expect more fluent performance with triplebuffer enabled since it enables a separate thread for rendering.

[oomek]

It’s a great find, as it’s not docummented anywhere. I will mark this thread as solved.

[Calamity]

It’s a great find, as it’s not docummented anywhere. I will mark this thread as solved.

Have you noticed any scroll stuttering due to triplebuffer?

[oomek]

No I haven’t. Only usual slowdowns from games’ cpu cap