Regression in z0r.de/1988 - sound became choppy

[Diatonator]

Describe the bug

In Nightly 2022-07-31 the audio in z0r.de/1988 became choppy.
I believe this is the nightly build where this change came about (at least for the web extension): #4273
And F12 spams with "Bad MP3" stuff:

Expected behavior

A non-choppy audio.

Affected platform

Browser's extension

Operating system

Windows 10

Browser

Chrome 103.0.5060.134

Additional information

No response

[torokati44]

Most likely the Symphonia decoder now in use is more sensitive to this kind of data corruption.
After some investigation, should perhaps be reported upstream to them.

[Diatonator]

I also see a regression here, but more serious as the audio is completely silent:
https://z0r.de/3682
The error is different:

[Diatonator]

While traveling through z0r, I noticed a whole bunch of loops having "invalid main_data_begin" errors, but there are mostly few of those errors in the console per loop, and they don't affect the heard audio. z0r.de/1988 seems to be the only loop which gets crusted by those errors, and there is a whole lotta them in the console.

[torokati44]

Yes, https://z0r.de/3682 is mute due to a separate issue, I just submitted a fix to that.
Thanks for the testing!

[Diatonator]

Another one partly crusted by "invalid main_data_begin":
https://z0r.de/3114

[torokati44]

The sound of https://z0r.de/1988 and https://z0r.de/3114 is now choppy even on desktop, where Symphonia is not used yet.
So this sounds like #3817 all over again... :/

[torokati44]

FWIW deleting just this line fixes the stuttering:

ruffle/core/src/backend/audio/decoders.rs

Line 329 in 2ba82c9

|| self.mp3_samples_buffered <= 0

In the problematic loops, self.mp3_samples_buffered is somehow negative from time to time, and it is for some reason not a problem unless we make it one...?

[Diatonator]

https://z0r.de/7637 also got crusted, but I see nothing in the console!
So maybe those "invalid main_data_begin" warnings are not that relevant?

[Diatonator]

As per Nightly 2022-08-17, https://z0r.de/7637 seems to work fine on my system, while https://z0r.de/1988 and https://z0r.de/3114 still have crust

[torokati44]

I think I have a guess for the reason for the "underflow by ... bytes" errors.
If I understand this correctly, right now, there is some continuous synchronization going on between the frame rate of the animation relative to the wall clock time (to keep the pace), and the actual progress in processing of the audio and visual portions (decoding, rendering, playback, etc.) of the frames.
This might cause the sync code to skip over a few frames, or at least the feeding of SoundStreamBlock contents to the MP3 decoder - under the assumption that this is always fine, given how robust and resilient of a format MP3 is.

Except that in this case, the code where the error originates from: https://github.com/pdeljanov/Symphonia/blob/398dab0af6d349849642f40664511c407fa935a0/symphonia-bundle-mp3/src/common.rs#L408
... is part of a "reservoir" mechanism, which makes this work:

[...] low-complexity portions of the audio may not need
/// every byte allocated to the frame. The bit resevoir mechanism allows these unused portions of
/// frames to be used by future frames.

Which means that sometimes there actually are dependencies between subsequent frames, and skipping the decoding of a frame (for synch. purposes, if the machine can't keep up the framerate) breaks this - which then breaks the frame which would re-use the bits in the reservoir, and this can then cascade endlessly.

This reservoir feature might, however, be used relatively rarely, which could by why there arent many more problems like this in Ruffle.

[Diatonator]

@torokati44 Good job on fixing "underruns" in those clips!
I found one (https://z0r.de/7805) which was "partly fixed" though, as some "underruns" and coughs are still present (In Adobe it sounds OK). Before the fix that SWF was unbearable to listen to whatsoever though.