|Re: [hatari-devel] Audio/video sync regression in dev-builds|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 10/05/2022 à 18:06, Anders Eriksson a écrit :
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
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
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
back in August I did the (what I think is correct) recording with 2.3.1. But just to be sure I re-did it now. And it works as expected, the sync is correct at the Pong part. So I can't re-create bad sync with 2.3.1.
When I recorded the Youtube thing it was done with macOS 10.4 x64, and the test today with macOS 12 AARCH64 in Rosetta 2 mode (no AARCH64 binary available of 2.3.1).
ok, that's strange because with 2.3.1 I have the sync problem here. I
will do a recording again, maybe I did sthg wrong.
Just to be sure, can you tell which command parameters you use when
running hatari to do a recording ?
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 :)
Does the syncsquare improvements also impact the STe PCM sound? The (profanity) demo is PCM only, not YM.
Not directly, but it changed slightly the YM "clock", which is used in
all cases when producing sound as the "master sound clock" and mixing
with DMA / Falcon sound (except that when using DMA sound only we
consider the YM only output 0 values when doing the mixing with DMA sound)