I can't speak for anyone's STe's, but here's a potentially disruptive datapoint for the above list: my own 1040 STF (with a sticker on the bottom suggesting a June '87 manufacture date, but with only the Nov '85 v1.00 TOS) that I have had eyes on the motherboard of in the last couple days... and was somewhat surprised to find had a 32.04245 MHz master crystal (so CPU/bus frequency of 8010612.5Hz) installed. From what else I've read about the crystals in STs, I was expecting something a touch slower. Oh, and it's a PAL machine... which never offered any suggestion of it being anything other than absolutely normal up until this point.
(It's not running at the moment so I can't use the speed measurement program in the linked thread, and in any case that seems to be dead since a couple years ago already)
Anyway, maybe slightly cold info, but something else that is worth considering when trying to precisely time STe audio and that I only found out to my surprise not that long ago: regardless of your actual system clock, the machine *also* has a 8.010613MHz crystal install *specifically* to run the DMA audio system. I had originally figured all STe's ran at 8.010613MHz (and so had a 32.042452MHz master crystal) given that the official very specific sample rate of 50066.33Hz is 1/160th of that frequency, hence the surprise at finding both different clocks for PAL/NTSC, and then the matching clock inside my STF. Presumably Atari developed the DMA system using that particular STF clock then found that for some reason they needed to change the actual system speed, after already defining the sample rates (strange that they never seemed to be that bothered about fiddling the monitor scan rates around as a side effect of changing clocks, or the Yamaha soundchip tuning and replay rate of software-produced samples), so had to include the additional clock. Otherwise the actual DMA frequencies would instead end up based off anything up to 50337.35Hz in some systems, which would produce a noticeable transposition of tuned samples...
So if you're having trouble figuring an accurate relationship between the DMA clock and the rest of the system... that's the reason. Not only is the relationship going to be different in an NTSC machine vs a PAL one (and particularly, make your samples go out of tune vs the YM on different machines if you use both in concert; particularly I think the TT uses the NTSC crystal regardless of region, so if you're in PAL-land and try to play something written on an STe on a TT or vice versa... bad news, like trying to play music from a PAL and NTSC Amiga in sync without genlocking them together), but the effect of temperature dragging the exact crystal frequency up or down could well act on one of the oscillators to a greater degree than the other and so cause them to desync in spite of your best efforts at precalculating the relationship.
Probably your only real way to lock them together is to use the CPU to throw values at the DACs directly, if that's even possible in the STe in the same way that it is in the Amiga... or at least set up a 2-sample buffer in memory, set the DMA rate to maximum, and just write the same value into both samples at your preferred replay rate (25kHz or less of course)...
Of course, there's always the option of modding your STe so the DMA system is fed from the main system 8MHz clock instead (snip a leg, run a single jumper wire... so long as it doesn't mess up the signal buffering...), and then there *should* be a constant cycle count per sample - 160 for 50kHz stereo, 320 for 50k mono/25k stereo, 640 for 25k mono/12.5k stereo, 1280 for 12.5k mono/6.25k stereo, and 2560 for 6.25k mono.
Now, a question... has anyone actually straightened out what the mono line count and therefore the vsync rate actually is, and if it's constant across all machines? The few results from that timer routine suggests 501 lines, but in other literature (including even SM-series service manuals) there's been about as much suggestion for that as for 500 lines, and the surrounding H/Vsync periods and frequencies are little help because they work out to all kinds of numbers from about 499.5 to 503.5 lines, including a lot of fractional answers and the hugely helpful 500.5... and the varying system clocks mean that Hsync can be from about 35.743 to 35.955kHz, with 500 lines meaning Vsync runs from 71.49 to 71.91Hz, or 501 meaning 71.34 to 71.77Hz (the oft quoted "35.714kHz" requires a clock of *exactly* 32MHz / 8MHz or in fact a little below, and "71.43Hz" is as close to 500 lines as rounding will allow when dividing down from there). Neither of them produce a "71.2Hz" outcome, and only 500 lines can be realistically called "71.5Hz" at the original (8.0064 and 8.010613MHz) clocks. In contrast, if we want to keep the same general Vsync (and so keep any VBL-linked routine running at the same speed, and certainly within ~2 sec per hour drift) with a TT / MSTe / NTSC STe clock, then it needs to be 503 lines instead...
It'd be good to get a digital scope on an example of every differently clocked machine to see what's what, but more practically a simple program that used successive VBL interrupts to start and then stop an HBL-linked counter then print the result successively across the screen (so squeezing in 28 per line with 6x6 font with a 5-pixel space in between each count, about 2.6 lines per second, filling 66 lines of text in about 25 seconds before halting, having made and written 1848 samples, which should be pretty statistically valid, then inverting the screen using a big blocky font to display the average out to 3 decimal places just to be sure... and similar in med rez just with only 33 lines, to check the colour modes) would do the job. Dunno how you'd make an accurate cycles per second count without reference to any other internal clock, though; I thought everything including the keyboard controller RTC came off the same main clock at the end of the day...?
Similarly, as well as there being internal hardware solutions to open up the monochrome screen into overscan sizes, I've seen that some software tricks are at least able to open up the right and lower borders (top left is about as tight to the syncs as you can get already, at least without holding DE permanently high) ... do we know what actual active pixel/line counts those routines produce, or can it be easily calculated? My own figuring from the already determined and published cycles and lines that various things (which are either skippable to produce overscan, or are absolutely enforced by hardware) happen suggests a fairly impressive 736x466, which isn't far off the supposed hardware overscans of 752~768 x 480... does that seem realistic?
(It's all largely academic, and my own purposes for the information are, at least at the moment, purely thought exercises, but I feel it might be useful for further emulator tuning as well as improving how scalers and framegrabbers deal with mono screens, seeing as their structure is rather unlike that of any particular Japanese, Apple or IBM compatible mode...)
And I suppose there's no way of controlling that stuff from an external module... Genlock only affects the pixel clock and nothing else, right? And there's no clock *output* of any kind anywhere, even the cartridge port, just input? (What clock rate do you even need to make the STe sync to standard video, in that case? Presumably exactly 32MHz for PAL, 31.972028MHz for NTSC, and you just hope the attached system doesn't absolutely demand 262.5/312.5 line interlace and will still be happy with 263/313 line progressive?)
Pulling all that together, has anyone actually produced usable interlace from any ST? There are hypercolour type demos that claim to run "704x440i" resolution (medium rez with rapid palette swapping, temporal dithering, and supposed interlacing on top?), but I don't know if that's true or is actually 704x220 with interframe flipping to increase the perceived colours. I figure you can manage something like it on a fully analogue CRT monitor or projector by running 64 lines of the "wrong" frequency (50 or 60hz) right at the top of every other frame, gradually advancing (60hz in place of 50hz) or retarding (50 in place of 60) the vertical raster position (by 4 cycles out of 508/512 per line) in relation to where it would be on a normal single-frequency frame, with it being shifted just enough to get away with by the normal start line of a 60hz screen, but that's only theory and it'd probably fail even on a digitally auto-adjusting multisync CRT, let alone any LCD TV or (LCD/DMD/laser) projector. Of course you could try running 8 lines of 71hz (50hz; or 10 x 71 and 12 x 50 for 60hz) with a Hsync-killing trick every other (71hz) line and hoping the screen is responsive enough to actually sync at ~18kHz for a few lines and so be able to produce interlace across essentially the entire visible height (whether the reverse might also allow mono interlace, though...)
...bit of a drag-on post, but that's a bunch of things I've been trying to figure out independently for a while and hit a wall without being able to properly clarify everything... as well as a little extra info that I hope is useful to someone in some way