Audio Library for Linear Timecode (LTC)?

Hi Frank,

I've been doing a bunch of testing with the LTC library, and I've noticed something. It works perfectly when playing audio over USB. But...less so when playing audio in via Line In on the audio shield.

Here's a link to a 1 minute file I have been testing with:

https://www.dropbox.com/s/7celrklbl9erhde/LTC_01_02_03_00__1mins_30.wav?dl=0

When I play this back via USB to the Teensy (3.2 for the moment) I can read the LTC and when I print it back via the serial port I see every frame, like this:
01:02:37.25
01:02:37.26
01:02:37.27
01:02:37.28
01:02:37.29
01:02:38.00
01:02:38.01
01:02:38.02
01:02:38.03

When I play back from the analog of my computer to the line in on the audio shield, I get this:

01:02:13.00
01:02:13.02
02:04:26.01
01:02:13.04
01:02:13.05
01:02:13.03
01:02:13.09

So clearly I'm not managing to decode each frame, and I get spurious misreads every once in a while.

I put a peak detector into my program so I can verify that both are coming in at the same level, and we are good there. I'm not exactly sure where to start on next. Any thoughts?

As I'm just using the decoder as a display for the moment the missing frames aren't the worst, I can't see individual frames anyway, they go by too fast. Those spurious reads way off in the middle of nowhere aren't great though, they cause the display to jump which is quite visible as a glitch.

Thank you!
 
Yup, seems to to be the startbit problem. It is repsonsible for exactly this : "doubled" time. Seems to work not reliable if the time between two frames is longer /shorter than the program is able to compensate.
Or maybe it takes a little too long to set everything right for the first bit. You can test it with a faster Teensy. Please report back if it helps.

You may want to add some plausibility checks to detect this condition (doubled time) and shift the whole info one bit back.
 
Hi Frank,

I will check it out. I just got some new T4 in so I should be able to try them at some point.

I had thought about adding a plausibility check and just not displaying the frame if it didn't seem to be from the right time, I will look into implementing that.

Do you have any theories on why this only happens on the analog input? The exact same file plays ok via USB.

Thanks!
 
No, not really.
Might be a signal degration or too high or low levels.

If you detect the "doubled" values, just shift it one bit to the right and you'll get the correct number. ( >> 1)
 
Hi Frank,

Just had a minute to solder up a T4 with an audio shield and test. I'm seeing similar results over line in:

01:02:05.19
01:02:05.21
01:02:05.22
02:04:10.01
01:02:05.24
01:02:06.01
01:02:06.03
01:02:06.04
01:02:06.06
01:02:06.07
01:02:06.08
01:02:06.09
01:02:06.15
01:02:06.17
01:02:06.18
01:02:06.19

Via USB it looks like this:
01:02:03.18
01:02:03.19
01:02:03.21
01:02:03.22
01:02:03.25
01:02:03.27
01:02:03.28
01:02:04.00
01:02:04.01
01:02:04.03
01:02:04.04
01:02:04.06
01:02:04.07
01:02:04.10
01:02:04.12
01:02:04.14
01:02:04.15

Still missing some frames, but no doubles. Not the worst for my purposes though.
 
Just a further note, I went back to my T3.2 setup and tried the ADC input. I'm seeing more glitches there, even a few quadruples! I played with input level a bit, and there does seem to be a sweet spot where the errors get less frequent.

I'll keep playing with it, but wanted to share my findings. I had a look at your code and while I have a vague understanding of where you are decoding the stream, I am not enough of an expert to try to figure out if I can improve something to help with this issue.

Thanks!
 
Interesting, I wonder if anything changed since I tested it a long time ago, I don’t remember seeing any missed or doubled frames, but I didn’t think to look for them either. I’m going to setup my rig again later and actually pay attention to glitches this time.
 
Feel free to change whatever you want (and do a Pullrequest)
From the beginning on, the code was meant as a starting point only, not a complete reday to use application.

I will be not here for some weeks, maybe months. But I'll keep watching github.
 
vjmuzik - I'd love to see if you're seeing similar results to what I am. If the link above to the file I am using to test doesn't work for some reason, just let me know.

Just to recap, I am seeing this on the analog inputs. While the USB input does sometimes miss frames, I don't see the doubling effect.

Frank - I hope you are ok! If I ever manage to figure things out to a level that I can to a PR, I will. You happen to be a much better programmer than I though!
 
I can test the audio file, but I have a Sync I/O that’s known good and it’s what I used last time.
 
I'd be very curious to see if the Sync I/O worked ok and the audio file didn't. Maybe that could help narrow down where this problem is creeping in.
 
hello
I am interested on a LTC (audio) to MTC (digital ) converter, if somebody could jumpstart me on the argument would be very kindly.
thank you in advance
 
Before I do something meaningless. :
The audio library uses 128 samples per block by default (but there is the possibility to use shorter blocks). At about 44.1 kHz this means 128*1/44100Hz = ~2.9ms per block. The output will therefore be inaccurate by at least this amount (possibly twice as much). Can you live with that?
If not, the audio library may be not the optimal place for it.

Why any inaccuracy? Single-sample granularity is just a case of returning the sample number for each timestamp,
or you can generate a click on a generated click-track stream to provide synchronization to the
sample granularity. You won't see more than one click per block so each click has an unambiguous timestamp.

By also recording the sample number of the latest two timestamps you allow easy time interpolation by sample number.
 
hello
I am interested on a LTC (audio) to MTC (digital ) converter, if somebody could jumpstart me on the argument would be very kindly.
thank you in advance

I've never done this and I'm not really sure how MTC actually works at a low level. However, I can say that using this library you will be able to derive the incoming time code. I did a quick google search and there do seem to be some projects for Teensy and Arduino that talk about being able to send MTC. Perhaps you can graft these two ideas together to make the converter you're looking for!
 
I've never done this and I'm not really sure how MTC actually works at a low level. However, I can say that using this library you will be able to derive the incoming time code. I did a quick google search and there do seem to be some projects for Teensy and Arduino that talk about being able to send MTC. Perhaps you can graft these two ideas together to make the converter you're looking for!

ok i will work on it
 
Last edited:
Hi, I hope this thread is still a bit active and someone can help me. I have the reading LTC working, USB and ADC input are working with just 1 frame latency and no skipping frames. But can't get the generator to work. I would like it to output on the DAC1. Is there anyone who has a working sketch for me to share? I'm fairly new on this forum, so I hope I'm not asking something wrong here? Olivier
 
Hi, I hope this thread is still a bit active and someone can help me. I have the reading LTC working, USB and ADC input are working with just 1 frame latency and no skipping frames. But can't get the generator to work. I would like it to output on the DAC1. Is there anyone who has a working sketch for me to share? I'm fairly new on this forum, so I hope I'm not asking something wrong here? Olivier

Just add an RC low pass to the output pin (by default pin1) - no need for a DAC. But don't make the waveform too smooth... it works better if it is still kind of a square. I remember there is a specification somewhere...
Or just use the digital pin as it is and make sure that the output-level is ok (simplest case: use a potentiometer). That works.
As said - this is not a ready to use application. From the beginning on it was said that it is a starting point for your own pograms - not more.
I have no usage for LTC, and will never have. I wrote the to code to help others to get started.

@MarkT: Add or subtract 1 to/from the frame number. That's it.
 
Last edited:
Sorry for the late "THANK YOU". It works like a charme now. Only have to figure out how to set the incoming TC to the outgoing TC. For the moment I see in the serial monitor the incoming TC, and it is outputting time of day TC.
 
Sorry for the late "THANK YOU". It works like a charme now. Only have to figure out how to set the incoming TC to the outgoing TC. For the moment I see in the serial monitor the incoming TC, and it is outputting time of day TC.

Yes, currently it just outputs the time of day.
May I ask why it should output the same time it receives? Wouldn't a simple wire do the same? I think i'm missing something here.. :)
 
I would like to grab the TC from a running camera. The teensy would loch to this TC. Then disconnect from camera 1, goto camera 2 and feed the same TC to camera 2.
 
Ah :)
Would it work to just set the teensy time of day to the received timestamp, at the moment of switching?
You can't do this with every receive - would lead to problems. Or you'll have to use a better approach with a "buffer" (just a uint64).
 
Would work, i think. Still have to test if multiple teensy's will stay sync for a few hours.

Don't think so.. the crystals drift, and it gets worse if their temperature varies. You'll need a higher precision time.
I'd add a high precision RTC like DS3231. It's not expensive.
 
Thanks, will look into that soon. Other questions. In your example you wrote.

To enable decoding:
#define USE_LTC_INPUT
and connect pin1 to pinA2 (=pin 16)

That is connectingvthe input to the output? If I do that nothing works....
 
Thanks, will look into that soon. Other questions. In your example you wrote.

To enable decoding:
#define USE_LTC_INPUT
and connect pin1 to pinA2 (=pin 16)

That is connectingvthe input to the output? If I do that nothing works....

Well I tested this, of course, and it worked... but OK, that was some time ago. Which teensy model do you use?
 
Back
Top