LTC out - jump in LTC phase after Windows wakes from screensaver

[mungewell]

This one is going to be a challenge to find, and it's totally OK to say "disable screensaver!".

I had left units connected running overnight and noticed that the LTC phase jumped when the PC 'woke' (just screen, not CPU). I was able to recreate again.

PicoTimecode is time master outputting MTC to PC, but we need to set it up first:

• Set STC to generate LTC from CPU clock
• Jam sync PicoTimecode to LTC from PC
• leave PicoTimecode in 'monitor' mode to get USB-UART report of incoming LTC
• Set STC for incoming MTC and outgoing LTC. There will be a jump in phase here, as there is delay through USB stacks, should be constant after that.
• Let PC idle so screen sleeps.
• Wake PC, and see a jump in LTC phase

Note: the reported LTC phase is in 1/640th of a frame, and only measures the timing of sync pattern - it does not evaluate the LTC contents. As such. without scoping the lines, I do not know whether this a forward or backwards jump, or by how much...

Note 2: As PicoTimecode is the master, any small difference in the XTAL/TCXO should not matter. The PC should exactly follow the incoming MTC.

This is done with the 'PT_Thrifty' board, super low-cost. The code will run on a Waveshare RP2040-Zero (or Pico-1) to output MTC via USB, but will need a comparator circuit to monitor the incoming LTC.

@fiverecords Judging from your Timezone (that GitHub tells me) you are somewhere in Europe, I can donate/post you a board if you'd like to test locally. Would also be a small thank you for writing such a cool application.

[fiverecords]

Thanks for the careful setup description — that makes it tractable. Since the Pico measures sync-pattern timing only, whatever moved is in the bit stream itself, and there are only two things in STC that can do that: the LTC output pausing on a source dropout and resuming (the phase then shifts by the length of the silence), or the audio device being restarted by the driver on a power event and the encoder re-seeding.

Four things would tell them apart, all on the build you have:

1. Enable HOLD ON PAUSE and repeat. The encoder keeps running through a pause, so if the jump disappears it's the dropout path.
2. Watch the MTC IN status while the screen wakes — does it flicker to no-signal?
3. Log the quarter frames across a wake with STC out of the loop (the styletronix monitor or MIDI-OX). A gap over ~150 ms in arrival times means the USB stack stalled, which is what would trigger the pause.
4. Same experiment with the generator (CPU clock) as source instead of MTC. A jump there points at the audio side, not MIDI.

Your note that the PC should exactly follow the incoming MTC is worth answering directly: today it follows the values, but the LTC bit clock is the audio device's clock, so the frame phase is aligned at the instant of a seed and then drifts at the clock difference until a whole-frame correction. A phase lock on the bit clock is the right fix for that family, and this issue is a good reason to build it — once I know which of the two mechanisms you're seeing.

And yes, I'd gladly take a board — thank you. It would let me measure this here instead of asking you to. I'll send an address privately.

[mungewell]

Your are correct, problem should exist with generator mode (and PicoTimecode in 'free run'). It does! It appears that the LTC from the PC has a 10ms gap, related to the PC waking from 'screen saver' sleep.

20260908_ltc_on_wake.zip

I forget about PT-Thrifty board only having one connector, so it mutes the output LTC when in Jam/Monitor mode, but still outputs 1PPS so we can use that to understand where the LTC frame starts.

The Putty log shows the reported phase jump

RX: 10:34:50:02 ( 250    -------:          ) 38.75
RX: 10:34:51:02 ( 251    -------:          ) 37.82
RX: 04:33:85.22 ( 251    -------:          ) 39.69
RX: 10:34:53:01 (-229           :+++++++   ) 36.41
RX: 10:34:54:00 (-229           :+++++++   ) 36.41
RX: 10:34:55:00 (-228           :+++++++   ) 38.75

At 25fps a report of '250' = 250/640 * 1/25 = 0.015625ms, and '-229' = -229/640 * 1/25 = -0.0143125ms.

I will note that my 'sound card' is a AV-FR2 audio recorder, connected via USB2.x port. I can try a few other sound cards to see if they also show the same behavior. Looks like the on-board one is not USB, but the audio quality was really bad for some reason...

[mungewell]

I dug out my Avid/M-Audio C600 USB2.x interface, and it started out looking OK... but then it went through a group of failures, where the LTC signal glitched. I'm not sure what could be creating the opportunity for failure.

[fiverecords]

Your captures settle it, and it wasn't either of the two mechanisms I proposed. From the FR-AV2 logic-analyser file: a single hole of exactly 10.00 ms in the LTC at the wake, 40.0 ms frame spacing everywhere else with one 50.0 ms interval straddling it, and the frame boundary against your 1PPS moving from +15.70 to +25.70 ms — a permanent shift. The C600 shows the same thing with a different size: 156 → −236 is 24.5 ms, which isn't a whole number of its 21.3 ms periods, so the hole is the length of the stall rather than of a device period. The interface stops, resumes the stream where it left off, and STC's encoder has no idea.

The next update will handle it: the encoder will watch its own callback cadence and, when the device has run dry, re-seed at the phase the source publishes — where the frame boundary should be now, whatever the hole was. One glitchy frame (the hole itself), then the same phase as before. The LTC status line will count these gaps, because an interface that keeps doing this is worth knowing about. When that build is out, your Putty log is the test: one corrupt read at the wake, then the pre-wake phase. The C600's burst of failures should show as a burst in the gap count.

One limit worth stating up front: this catches holes that delay the callback. A hole the device makes while still calling on time is invisible to it, and the answer to that family is a continuous phase lock on the bit clock — which is exactly what your board will let me build and measure.

[mungewell]

I'm glad you have an idea, even if I didn't fully understand... Q. how many buffers do you have (preloaded into/for the sound system)?

a single hole of exactly 10.00 ms

To be pendantic, it's not exactly. Pulse view limits the digits depending on zoom, and the 'rising' to 'failing' edges which span the 'hole' should actually have some expected time between them. Rising at 1053400us, failing at 1063400, expected width is 250us... so delay is 9750us.

I ran some tests with a Firewire audio card Moto 896, and only once saw a glitch... I tried for a long time and did not see anything again, so I'm not really sure it was a 'hole' issue... will keep trying later. Back to the C600 to see if I can repeat with that.

Once you have a new build, are you saying we might still get holes but that the LTC will compensate for them? Surely better to prevent the hole in the first place...

[mungewell]

Q. When STC is in 'generator' mode, what/who regulates/determines the progression of time? CPU clock or audio interface's clock?

If external, if STC doesn't know the length of the gap any attempt to restart will result in a jump in phase.

I have the C600 and 896 set up with an external "reference" word-clock, and the same word-clock is driving my Sync-IO which generates a LTC signal so I can calibrate my PicoTimecode to the reference clock. After calibration the (supposed) 12MHz TCXO is 'pulled' by around 21 PPM.

Checking '25' fps:
Calibration    : -15.0859376
Ideal divider  : 2812.500000 (at 25.000000 fps)
Calc divider   : 2812.5588
Calc XTAL freq : 12000251.0

It's likely that neither the PicoTimecode TCXO nor the reference clock is absolutely correct, unless/util Santa reads my letters I don't have the ability to know for sure.

[mungewell]

I scoped out some failures with the C600 audio interface (USB 2.x). Similar, but of note which we didn't see in the AV-FR2 (single) capture is that the data is not just delayed, there are transitions within the 'gap'.

20260909_c600.zip

[fiverecords]

Those four captures are worth more than they look. Measured from the .sr files: each wake is a 40–49 ms event made of two quiet stretches (21–36 ms and 2–25 ms) with a handful of LTC transitions between them — the driver playing a fragment of a stale or partial buffer — and the net phase shift afterwards is −2 to −7 ms, different every time and never the length of the event. A clean pause would shift the phase by the pause. So the C600 both delays the stream and drops part of it during the stall, which is exactly why the recovery must not try to measure the hole: it re-seeds from where the source's clock says the frame boundary is now, and what the interface did in between is irrelevant to it.

On your other questions:

Buffers: STC preloads nothing of its own. With ASIO it is the driver's double buffer — two periods of the BUFFER SIZE you set, STC fills one per callback; WASAPI and DirectSound keep their own small ring. A hole is the driver's stream stalling, not STC running out of audio.

9.75 ms — agreed, and it matters: a stall length, not a device period, and the C600 confirms it from the other side.

Clocks: in generator mode the timecode advances on the CPU clock; the interface's clock only drives the bit stream that carries it. That is how STC always knows where the frame boundary should be, independently of what the audio stream did, and why a restart lands on the right phase without knowing the hole. The price of two clocks is the slow drift you will be able to measure against your word-clock reference: the bit stream walks away from the timecode at the difference between the two clocks, corrected today only in whole frames. A continuous lock of the bit clock to the timecode clock removes that, and it also catches a hole the interface makes without delaying STC's callback, which the cadence-based recovery cannot see. Your Sync-IO setup is the rig to measure both.

Preventing the hole: not STC's to prevent — the display wake stalls the host's USB or FireWire stream for the length of a power transition, below the application, and a bigger buffer does not help because STC was not late, the device was. What the next build gives you is a way to tell which: the gap counter in the LTC status line only increments when STC's own callback arrived late. A hole in your log with no gap counted means the interface stalled on its own, and that is the case for the lock. The 896 glitching once and never again sounds like it might be that kind.

[mungewell]

Whilst STC is outputting via the C600 (to both 1+2), I used my FR-AV2 as a standalone recorder (ie not via USB) to record the actual audio whilst the glitch happens. The glitches I mentioned above are actual short fragments of the LTC wave-form.

I can think of two possibilities:

• USB transfer to the device is stalled mid streaming
• STC's writes are immediate be transferred to the device, and not independently buffered. I think this is unlikely...

RX: 10:55:26:13 (-162           :+++++     ) 37.35
RX: 10:55:27:13 (-162           :+++++     ) 35.01
RX: 45:75:28:06 (-162           :+++++     ) 38.29
RX: 10:55:29:12 (-287           :++++++++  ) 37.35
RX: 10:55:30:12 (-287           :++++++++  ) 37.35
RX: 10:55:31:12 (-287           :++++++++  ) 37.82
RX: 10:55:32:11 (-287           :++++++++  ) 37.35

Is there anyway to determine/log the boundaries of the buffers that STC produced?

[mungewell]

Looking at the tail of the wafeform at the start of the glitch, it does something LTC should NOT do... it plays at 'zero' for a few samples.

The fragment may be a replay of this section.

EDIT:
Also the tail starts 'heading to high' early, even if this bit was encoding a 'one' (short/double pulse) it should be long duration in the 'low' state.

[mungewell]

Yesterday I ran more tests, and noticed a slight different failure. The 'pause' in LTC occurred, but did not affect the phase afterwards.

20260910_896.zip

I can also confirm that both these issues occur on all my devices; FR-AV2 and C600 (on USB), and MOTO896 (on Firewire) see this problem. I'm going to pause looking at this until new version of STC is available, hopefully the suggested changes will fix issue....

[mungewell]

I've been sharpening my tools, with a LTC decoder for Pulseview/sigrok-cli.

Submitted to the development mailing list, but if you want it now you can extract the contents (Python script) of zip into C:\Program Files\sigrok\PulseView\share\libsigrokdecode\decoders and it magically works.
ltc.zip

Using sigrok-cli you can also out text files with decoded 'frame' numbers, add --protocol-decoder-samplenum to add sample numbers. Which might give a path for automated analysis and comparisons of files.

[mungewell]

Maximum buffer length is 2048bytes, at 48K and various fps this is:

• 25fps: 1 frame = 1920samples
• 30fps: 1 frame = 1600samples

@fiverecords For debugging can we have:

• longer buffer, 4096 or 8192
• alternate one bit of LTC (bit 58 = clock?) each buffer. So we see it set high for a couple of frames, and then low for a couple of frames.

EDIT:
Or place a 4-bit count of which buffer into ALL the userbit (8x) locations, this is requested so we can understand where the buffer boundaries are.

[fiverecords]

Your audio recording is the piece that was missing. Zeros for a few samples, then a fragment of old LTC, then the new waveform from the middle: that is what a late callback looks like on a double-buffered ASIO driver. The driver starts playing the buffer STC has not filled yet — stale content from two periods back, your fragment — STC's clear-then-fill lands while it is already playing (the zeros), and the rest is the new data from wherever the write had got to. Your "STC's writes go straight to the device" is not unlikely at all; it is how ASIO works, there is no queue in between. And it means the callback was late, which is precisely what the next build detects and recovers from. The 896 pause that left the phase untouched is the other flavour: the driver dropped what it could not play and stayed on schedule; the recovery is harmless there, it re-seeds to where the encoder already is.

Buffer boundaries: both of your requests will be in the next build. Buffer sizes go up to 4096 and 8192, and the LTC user bits get a DEBUG: BUFFER COUNTER mode that puts the low four bits of the callback count in every binary group, so your decoder shows which buffer each frame was packed in; at one frame per buffer the digit steps every frame. I went with the user bits rather than bit 58 because that bit is BGF1 and now means something. On top of that, every detected gap is written to a log next to the settings file — time to the millisecond, engine, device, how late the callback was, and the device period — so the log, the counter and your captures line up.

The sigrok decoder is a real contribution; the sample-numbered frame output is exactly what automated comparison of captures needs, and I'll use it. Thanks for all of this — pausing until the build is out is the right call, and I'll say here when it is.