Video Juddering in Windowed Mode

[andres-asm]

From @Awakened0 on September 20, 2016 3:8

I have a build from 9/18/16 that runs smooth as butter, but the latest buildbot build from today (9/19/16) runs all stuttery. Almost like Vsync isn't working? The difference between the old and new build is easy to tell by just moving around the main town in FF1 in the Dawn of Souls remake.

Copied from original issue: libretro/mgba#43

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[andres-asm]

From @sergiobenrocha2 on September 20, 2016 10:43

Press F twice to fullcreen --> window --> fullscreen, see if it fix

[andres-asm]

From @sergiobenrocha2 on September 20, 2016 10:55

Btw, are you using a joypad?

[andres-asm]

From @Awakened0 on September 20, 2016 17:51

I was testing it with keyboard, but also can use my Xbox One pad.

Switching screen modes doesn't seem to fix it. But, I was testing in windowed mode, where the stuttering is much worse. In full screen, I only notice the occasional hitch on the latest nightly compared to the old build. Both GL and Vulkan have the same behavior.

[andres-asm]

From @sergiobenrocha2 on September 20, 2016 18:0

What OS? Tell us the specs

[andres-asm]

From @Awakened0 on September 20, 2016 18:13

Windows 10
i5 2500k
GTX 970, 372.54 Drivers

[andres-asm]

From @Ryunam on September 20, 2016 19:31

I can confirm the same exact drop in performance. There is a major and highly noticeable difference if compared to any build prior to the very recent 0.5 update.

I have performed some extensive tests using two different builds, '0e19' and '851db', which I had kept from some previous RA setups. With both 0e19 and 851db I get very smooth performance, perfect audio and video sync, no trace of stuttering and I can both raise Frame Delay and decrease Audio Latency (as low as 16ms!) with no apparent side effect on gameplay.

On the contrary, mGBA 0.5 can't seem to sustain 16ms of Audio latency at all: it turns to a choppy and unresponsive mess. If I raise that parameter to 32ms, it goes back to playable status, however both in fullscreen and windowed the whole execution constantly stutters, hitching every 1.5 second. It seems as though it has a hard time maintaining a stable framerate, whichever is the content you load.

EDIT: Upon further notice, on my machine I can obtain smooth performance again if I raise the Audio Latency back to the default 64ms. Still, I guess there is a very clear performance difference between 0.4 and 0.5, with the former being much more flexible with said audio adjustments.

OS: Windows 10 x64
CPU: i7 4790K
GPU: Nvidia GTX 970 with latest drivers

[andres-asm]

From @sergiobenrocha2 on September 21, 2016 0:41

I'm testing on Linux (xubuntu 14.04), with Alsa driver, 48 ms latency. Even the times I get choppy audio, the FPS remains at 60... it's triggered randomly when I just load the core, I can notice in the bios screen; sometimes happens when I plug a joypad. Going to window and coming back to fullscreen seems to fix it (Alt Tab too).

Is it the same issue?

[andres-asm]

From @Awakened0 on September 21, 2016 1:7

My pad is always plugged in, so I don't think hotplugging is causing it.

[andres-asm]

From @twinaphex on September 21, 2016 2:42

@endrift Any thoughts on this?

[andres-asm]

From @endrift on September 21, 2016 2:51

@sergiobenrocha2 poked me like 4 times about this and I've never had any concrete ideas. Moreover, I'm not going to poke at this seriously for at least two weeks; I burnt out pretty hard trying to get 0.5.0 out so I'm taking some time to recover.

[andres-asm]

From @endrift on September 21, 2016 2:55

I will bring attention to this line of code, though: https://github.com/libretro/mgba/blob/master/src/platform/libretro/libretro.c#L290

I wonder if the fact that you went from a frame-based audio approach to a discrete packet based approach broke your buffering somehow. I'd tried to read your paper on dynamic rate control at one point, but it left so many terms undefined and a lot of parameters unexplained, so I'm not actually sure if it could be related.

[andres-asm]

From @Sigmavirus on September 21, 2016 4:45

Can't really say that I experienced this kind of stuttery that's been talking about here when I tested it yesterday on my machine using the latest core (I came previously from an older mGBA core from May this year)

Played a couple of games around 5-10 minutes each and they were smooth as butter, this was also with VSync enabled and nothing else changed.

These are my specs BTW

i7 4790K @ 4.0GHz
AMD R9 380X 4GB GDDR5 (Crimson 16.3.2)
16GB Corsair XMS3 DDR3
Windows 10 Anniversary Update RS1 x64

Is there something special you have to do enable to notice the stuttery?

[andres-asm]

From @Ryunam on September 21, 2016 11:36

@Sigmavirus : you can try testing both a previous core and the new 0.5 build with Hard GPU Sync ON, 32ms of Audio Latency and switching between Windowed and Fullscreen during gameplay.

[andres-asm]

From @Sigmavirus on September 21, 2016 12:1

That sounds like quite an unusual use/test case scenario and not something I normally do but OK.

[andres-asm]

From @sergiobenrocha2 on September 21, 2016 22:14

For who wants to test aliaspider patch:

--- src/platform/libretro/libretro.c    2016-09-21 19:09:12.817187000 -0300
+++ src/platform/libretro/libretro.c_patched    2016-09-21 19:10:54.449927408 -0300
@@ -46,7 +46,7 @@ static retro_set_rumble_state_t rumbleCa

 static void GBARetroLog(struct mLogger* logger, int category, enum mLogLevel level, const char* format, va_list args);

-static void _postAudioBuffer(struct mAVStream*, blip_t* left, blip_t* right);
+//static void _postAudioBuffer(struct mAVStream*, blip_t* left, blip_t* right);
 static void _setRumble(struct mRumble* rumble, int enable);
 static uint8_t _readLux(struct GBALuminanceSource* lux);
 static void _updateLux(struct GBALuminanceSource* lux);
@@ -221,7 +221,7 @@ void retro_init(void) {

    stream.videoDimensionsChanged = 0;
    stream.postAudioFrame = 0;
-   stream.postAudioBuffer = _postAudioBuffer;
+   stream.postAudioBuffer = 0;
    stream.postVideoFrame = 0;
 }

@@ -288,12 +288,12 @@ void retro_run(void) {
    videoCallback(outputBuffer, width, height, BYTES_PER_PIXEL * 256);

    // This was from aliaspider patch (4539a0e), game boy audio is buggy with it (adapted for this refactored core)
-/*
+
    int16_t samples[SAMPLES * 2];
    int produced = blip_read_samples(core->getAudioChannel(core, 0), samples, SAMPLES, true);
    blip_read_samples(core->getAudioChannel(core, 1), samples + 1, SAMPLES, true);
    audioCallback(samples, produced);
-*/
+
 }

 void static _setupMaps(struct mCore* core) {
@@ -629,7 +629,7 @@ void GBARetroLog(struct mLogger* logger,
 #endif
    logCallback(retroLevel, "%s: %s\n", mLogCategoryName(category), message);
 }
-
+/*
 static void _postAudioBuffer(struct mAVStream* stream, blip_t* left, blip_t* right) {
    UNUSED(stream);
    int16_t samples[SAMPLES * 2];
@@ -637,7 +637,7 @@ static void _postAudioBuffer(struct mAVS
    blip_read_samples(right, samples + 1, SAMPLES, true);
    audioCallback(samples, SAMPLES);
 }
-
+*/
 static void _setRumble(struct mRumble* rumble, int enable) {
    UNUSED(rumble);
    if (!rumbleCallback) {

[andres-asm]

From @endrift on September 21, 2016 22:15

I figured out an issue with GB audio/video that could cause the streams to desync; It's fixed now, but that might be what the source of that comment was.

[andres-asm]

From @Awakened0 on October 6, 2016 23:42

I tested out 0.5.1 from the buildbot and the stuttering in windowed mode is still there unfortunately.

[andres-asm]

Yeah I finally managed to understand what's going on here.
Looks a bit like a panning scene on a 23.976 movie watched at 60hz, every half a second or so there is a bit of judder, as if it had to compensate the scrolling to match the audio every few frames.