Change in music pitch when switching to NTSC with 50Hz PAL and LL Vsync

[Foebane]

When I ran this (mostly) 50Hz demo (http://www.pouet.net/prod.php?which=409) with Default Refresh Rate and no Vsyncing of any kind (set in Display) then the two 60Hz parts which come on play fine as usual (that is, those that start at 2:59 (rotator) and 4:50 (Mandelbrot zoom) in the YouTube video) but when I select 50Hz PAL and LL Vsync, the music in the 60Hz parts audibly slows down a fair amount, and I'd say the action on screen is slowed down as well. When the demo goes back to 50Hz, everything resumes at normal speed.

I remember running this demo on my real A1200 back in the day, and I think the 60Hz parts were only meant as a speed boost for those parts, but the music was unaffected. So why does this happen with these settings? I figured the 50Hz PAL setting would be like using a real Amiga with a PAL TV, so anything in NTSC mode wouldn't be affected sound-wise.

I've included what I think you need, but let me know if I need to provide more files.

[th4t1guy]

There are more horizontal pixel lines in PAL than NTSC, so it takes more cycles to draw the screen. The demo is coded against the screen refresh, so you end up getting a noticeable slow down.
Most demos are intended to run in PAL.

[Foebane]

Originally Posted by th4t1guy

There are more horizontal pixel lines in PAL than NTSC, so it takes more cycles to draw the screen. The demo is coded against the screen refresh, so you end up getting a noticeable slow down.
Most demos are intended to run in PAL.

Yes, I know, but "Love" and a few other demos had NTSC parts.

However, the only change in music playback should be in tempo, not pitch. I know this from personal experience.

[Foebane]

I've just confirmed it outside of demos by going to Workbench in both PAL and NTSC and running a few music modules in HippoPlayer: there is definite slowing of both tempo and pitch in NTSC. It should be only tempo that changes, and that should be faster.

[britelite]

Originally Posted by Foebane

However, the only change in music playback should be in tempo, not pitch. I know this from personal experience.

Actually, if you use a PAL-pitchtable in NTSC (or vice versa), the pitch will change.

[Foebane]

Originally Posted by britelite

Actually, if you use a PAL-pitchtable in NTSC (or vice versa), the pitch will change.

Is a pitchtable something along the lines of a list of frequencies used by a musician to replicate musical notes on a computer?

In any case, I'm not sure what to think now. If I recall, "Love" must've switched back and forth between PAL and NTSC because I tried recording it on a VHS tape, and it screwed up the recording when it went to NTSC. And yet I'm certain the music remained unchanged on the real A1200 hardware I used.

[britelite]

It does play just fine on a real A1200, but you seem to be forcing it to play in PAL 50hz in WinUAE so the music will naturally slow down (EDIT: with the assumption that the modplayer is tied to the VBL)

[Foebane]

Originally Posted by britelite

It does play just fine on a real A1200, but you seem to be forcing it to play in PAL 50hz in WinUAE so the music will naturally slow down (EDIT: with the assumption that the modplayer is tied to the VBL)

I'm using a 50Hz 1080p mode on my Nvidia card, so as to match the PAL refresh rate of the Amiga.

As a result, I'm reinforcing the 50Hz PAL mode in addition, because I was told by someone here that it was the only way of ensuring silky smooth scrolling graphics etc. just like those on real hardware on an old CRT. If I'm wrong in that regard and I can just use the "Default Refresh Rate" for exactly the same effect in both PAL and NTSC, then I will change my configs accordingly.

[mark_k]

When you enable vsync, WinUAE adjusts the emulated Amiga speed so 1 Amiga frame takes the same time as one PC frame. So with 50Hz 1080p the emulated machine runs at (almost) the correct speed when in PAL mode.

When the emulated Amiga switches to NTSC however, emulation is slowed so that one Amiga frame (which would take ~1/60 sec on a real Amiga) still takes ~1/50 sec.

You could try using the "Low Latency VS, 50/60Hz" option in WinUAE display settings. With that, WinUAE will hopefully switch the PC video mode between 50Hz and 60Hz depending on the Amiga mode. But there could be issues there: your monitor blanking for a short while, the Windows desktop flashing, sound glitches as the mode changes.

I wonder whether a "vsync as long as it doesn't alter Amiga speed much" setting could be useful for WinUAE. With that, you'd be vsynced to 50Hz, but when the Amiga mode changes to NTSC, WinUAE would automatically revert to non-vsynced mode. And back to vsynced once video mode changes to PAL again.

[Foebane]

Originally Posted by mark_k

You could try using the "Low Latency VS, 50/60Hz" option in WinUAE display settings. With that, WinUAE will hopefully switch the PC video mode between 50Hz and 60Hz depending on the Amiga mode. But there could be issues there: your monitor blanking for a short while, the Windows desktop flashing, sound glitches as the mode changes.

Just tried it: yes, my monitor did blank out between PAL/NTSC switches, and whether or not there were sound glitches or not, I couldn't hear, because I use the HD audio driver so the audio goes out through HDMI and is output to a headphone socket on the monitor. But when I did hear the music, it was fine again.

[Foebane]

Thinking about it now, I'd rather have a change of pitch rather than my entire monitor switching back and forth, with the resulting seconds of silence each time.

Where's Toni when you need him? I'm surprised he hasn't waded in this thread yet. He must be incredibly busy.

[Toni Wilen]

Mark_k already answered it. There is nothing else to add, everything works as designed

[FrodeSolheim]

Originally Posted by mark_k

I wonder whether a "vsync as long as it doesn't alter Amiga speed much" setting could be useful for WinUAE. With that, you'd be vsynced to 50Hz, but when the Amiga mode changes to NTSC, WinUAE would automatically revert to non-vsynced mode. And back to vsynced once video mode changes to PAL again.

This is actually how v-sync is implemented in FS-UAE (In reality, the video thread is still syncing to vblank, but the emulation thread is not synchronized with the video thread when the emulation refresh rate differs from the host system)

[Toni Wilen]

I don't call that vsync. Vsync that duplicates or drops frames is not a proper vsync.

[FrodeSolheim]

When host refresh rate ~= emulation rate, the vsync is full and proper with explicit synchronization between threads, of course. No duplicates or dropped frames.

[Toni Wilen]

Originally Posted by FrodeSolheim

When host refresh rate ~= emulation rate, the vsync is full and proper with explicit synchronization between threads, of course. No duplicates or dropped frames.

No, it can't work 100% glitch free. (without g-sync/freesync).

AV sync will slowly drift (without feedback loop) and cause dropped or doubled frame every n frames or sound buffer overflow (which practically means doubled frame) or underflow (sound glitch). n can be very big number but it will happen, sooner or later.

[Foebane]

So what does "50Hz PAL" do, if not lock the emulation at exactly 50Hz? Does "Default Refresh Rate" do exactly the same thing?

When I the above it was locked at 50Hz, but I was still getting tearing on the screen. That was when someone suggested "Low Latency VSync" to me and then it went away.

So what actually locks it fully into the right FPS? As far as I can tell, LLVS simply prevents tearing.

[Toni Wilen]

It locks to 50Hz (assuming your display/driver/card supports it). Every display mode is forced to 50Hz, including NTSC modes (=you get wrong sound pitch)

Note that emulated Amiga still runs at originally configured speed and compatibility level won't change. Only what you hear and see is wrong

[Foebane]

Originally Posted by Toni Wilen

It locks to 50Hz (assuming your display/driver/card supports it). Every display mode is forced to 50Hz, including NTSC modes (=you get wrong sound pitch)

Note that emulated Amiga still runs at originally configured speed and compatibility level won't change. Only what you hear and see is wrong

Is this a unique WinUAE peculiarity or do other emulators or video software do this?

[Toni Wilen]

Originally Posted by Foebane

Is this a unique WinUAE peculiarity or do other emulators or video software do this?

Vsync always forces selected refresh rate, there is no way around it. (again, unless gsync/freesync which allows instant on the fly rate changes)

Note that winuae vsync means forcing emulator and display to use same updating rate. Without vsync display buffers are still vsync swapped if triple buffered mode (=no tearing). Also in double buffered too but it also have some extra conditions..

I am not sure about sound pitch adjustment to match vsynced display refresh rate but it is far better this way, without it sound would glitch continuously. (Display panel FPS.Adj does the same without vsync)

EDIT: Note that on the fly PAL/NTSC switch is rare (or at least very rarely used) on other systems.