Re: [hatari-devel] Audio/video sync regression in dev-builds

[ Thread Index | Date Index | More Archives ]

Le 08/05/2022 à 15:44, Anders Eriksson a écrit :

I've been meaning to report this for some time but.. lazyness or something came in between. However now when Styckx is about to release 2.4 I guess it would be nice if these things were fixed.

First one, a long time ago when I recorded the Overlanders demo "First Love" the recorded file had audio/video sync errors. It's easy to spot at the Pong-game part. During recording the sync on screen is fine, only the output video is wrong. Video below with Hatari dev built 2022-05-07 by Troed. macOS 10.14 x64.

Demo download:

Recording with Hatari 2022-05-07, PONG part at 8m:


For the 1st one, I can create the same wrong sync with devel version, but if I test with 2.3.1 too, then I also have the same bad sync around 8min. Do you confirm sync goes bad too with 2.3.1 ? If so, does it work better with hatari 2.2 or 2.1 ? (it's possible this drift between audio / video has always existed more or less and becomes noticable only with large video). In the end, it could be related to how fps is stored inside avi file and maybe there's a bad rounding (we have maybe 0.6 sec of shifting between audio and video after 8 min, which would be a 0.1 % error, not that much :( )

Second bug, I'm not sure if it's related, but it's also about audio/video sync. We did a demo a few weeks ago and then we noticed that the audio/video sync was very off with the development build of Hatari, while 2.3.1 is OK like a real STe-machine. The sync is wrong both on screen and in the recorded video.
Tested with macOS 10.14 x64 and macOS 12 AARCH64.

Will check that later, I don't think it's related to the 1st point where saved avi file is not correct while on screen emulation was correct.

Demo download:

Correct reference recording with Hatari 2.3.1:

Recording with Hatari 2022-03-26:

Recording with Hatari 2022-05-07:

The 2022-03-26 version goes wrong around 12s, and the 2022-05-07 version goes wrong around 2m28s. It's easy to see the waveform difference if loading all mp3's into Audacity or similar.

that's quite possibly related to the changes I made to support syncsquare sound (as in used in maxYMiser v1.53) as it can impact how many audio bytes are output, although it should be more precise than before, not the opposite :)

Thanks for your hard work with Hatari, it's much appreciated :)

and thanks for the detailed reports :)


Mail converted by MHonArc 2.6.19+