Timecode display is one minute ahead of reality

[jaybird110127]

I just noticed that the timecode displayed with the -v option is for the minute after the one which starts to play once it is printed. E.G. timecode for minute 32 is printed as audio from minute 31 begins to play. I assume it's printing the timecode for the minute whose audio it just generated rather than the minute whose audio is about to play. This doesn't really matter to me, but it just seems that from a visual perspective, the most recent thing we should see should correspond to what we're currently hearing.

[ka9q]

Is this a newly introduced bug, or has it always been there? I did some code cleanup last night that shouldn't have affected functionality. Just to make sure, the transmitted timecode is correct, it's only the -v debug display that's incorrect?

…

On 3/18/23 00:35, Jayson Smith wrote: I just noticed that the timecode displayed with the -v option is for the minute after the one which starts to play once it is printed. E.G. timecode for minute 32 is printed as audio from minute 31 begins to play. I assume it's printing the timecode for the minute whose audio it just generated rather than the minute whose audio is about to play. This doesn't really matter to me, but it just seems that from a visual perspective, the most recent thing we should see should correspond to what we're currently hearing. — Reply to this email directly, view it on GitHub <#1>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADJDI47ZA42TMP6ZNTJEPJ3W4VQTZANCNFSM6AAAAAAV7KDNEY>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[jaybird110127]

This bug is present in the version I compiled in November of 2018, so I assume the bug was introduced when you made the switch to Portaudio. I just never noticed it before since I don't use the debug mode. Yes, the BCD timecode actually output during each minute is correct for that minute, it's only the debug printout that's one minute ahead of reality.

[ka9q]

I checked the new restructured version I released last week, and it works as you'd expect. It starts by generating the current minute's program, printing it, and starting the audio at the appropriate time in the current minute. Then it prints the programs for the next few minutes as it primes the output queue to ensure it doesn't run dry. It will then block until the queue drops a minute before it generates the minute after that, and so on. This was the major reason for the restructure: to allow an arbitrary number of minutes to be generated in advance to avoid an underrun because of a slow new speech synthesizer (piper).

[ka9q]

If your problem is resolved, I'd like to close this issue.