runloop: read the audio pace bit from the driver's blocking state

542c5abdbc set RUNLOOP_PACE_AUDIO from the audio_sync setting. The
setting is not the state. Fast-forward switches the driver to
non-blocking for a few frames with audio_sync still true, and during
those frames audio_driver_write() returns immediately and holds
nothing. A policy built on the setting - "a hardware clock is live, so
skip the timer" - would have removed the fast-forward limiter in that
window and let it run unbounded with audio_sync on.

AUDIO_FLAG_NONBLOCK is maintained by audio_driver_set_nonblock_state(),
the same call that flips the driver, so it is the actual blocking
state. Read that.

No behaviour change: the bit is still only recorded, and the timer
gate it sits beside is unaffected.

runloop.c

@@ -8269,8 +8269,12 @@ end:
    runloop_st->pace = RUNLOOP_PACE_NONE;
    if (settings->bools.video_vsync)
       runloop_st->pace |= RUNLOOP_PACE_VSYNC;
-   if (     settings->bools.audio_sync
-         && (AUDIO_FLAGS_GET(audio_st) & AUDIO_FLAG_ACTIVE))
+   /* The live blocking state, not the audio_sync setting. Fast-forward
+    * puts the driver into non-blocking mode for a few frames while
+    * audio_sync stays true, and during those frames audio is not
+    * holding anything. */
+   if (     (AUDIO_FLAGS_GET(audio_st) & AUDIO_FLAG_ACTIVE)
+         && !(AUDIO_FLAGS_GET(audio_st) & AUDIO_FLAG_NONBLOCK))
       runloop_st->pace |= RUNLOOP_PACE_AUDIO;
    if (     settings->bools.video_scanline_sync
          && video_st->scanline[SCANLINE_NEXT])