Jump to content

LTC reading from a raspberry pi?


Neil Bliss
 Share

Recommended Posts

Denecke's TimeCode Toolbox on iOS can display and output LTC as well as accepting input of LTC signal and display it.

 

I tested it on an old iPhone SE and setting TC Toolbox to output LTC and then jam the USOne worked great.

But on the SE the app did not listen to anything else but the microphone as input.

 

Not sure why but it should work.

Will do some more tests.

 

Edit: might be I need to get a trs-trrs for this.

Link to comment
Share on other sites

I recently came across this:

 

https://github.com/martim01/pam

 

Seems to fit the bill, as it claims to do LTC reading and generation, via audio input hat or AES67 on .

 

Also has some other interesting metering stuff. I haven't made one myself, but I am tempted to give it a try - just not quite enough use for it at the moment to devote the time.

 

James

Link to comment
Share on other sites

  • 5 weeks later...

I feel there’s too much to go wrong with running an entire Linux distro just to read and decode timecode.

 

I have a teensy with an audio hat lying around, I’ll give it a go with one of these libraries:

https://github.com/FrankBoesing/LinearTimecode-Decoder
https://0110.be/posts/LTC_-_SMPTE_Decoder_on_Teensy

 

would then be easy to outputbto one of these:

 

https://core-electronics.com.au/gravity-8-digital-led-segment-display-module-red.html?utm_source=google_shopping&gclid=Cj0KCQjw_dWGBhDAARIsAMcYuJxotl_6SXlm8klcWeddKJa-Xs7MdwfT0HCEhnYsP5Pl5oq83kAYy70aAmk5EALw_wcB

Link to comment
Share on other sites

3 hours ago, Riley McCullagh said:

I feel there’s too much to go wrong with running an entire Linux distro just to read and decode timecode.

You are missing a few essentials:

The 'sync word', defines the END of a frame. Thus, you only know the TC AFTER it has passed.
You can state that the sync word defines the beginning of a new frame, but that only works on continuous TC, and you still need to compensate for the duration for the sync word.
Next, there is no checksum or whatever in the bits, so you need to do a bit of error checking and freewheel a couple of frames if there is a glitch.
This all takes time that has to be compensated for to get a proper 'sync' display.
(Let alone the latency in the display, and in the audio device.)
That can all be done in (cheap) hardware, but it's not as easy as in a normal computer environment, and will only pay off on large volume production.

 

Link to comment
Share on other sites

Excuse my ignorance. But with known quantity near bare metal hardware you can predict the latencies of a lot of these issues surely? Such as incrementing the frame counter by 2 from incoming, and then delaying output by inverse of combined measured latency of dac + 7 segment display chips. You could also sanitise incoming against errors, comparing expected to received. Not the same as running an actual clock, but seems at least similarly reliable to an rtc in a normal computer. 
But I’m just a dabbler in hardware!

Link to comment
Share on other sites

  • 11 months later...

I don't recommend anything special, but I DO recommend you test.
Since there can be delays close to everywhere (display, incoming / sending over Tx Rx, latency of an AD converter, silence before your clap sound etc), LTC convert accepts an offset (positive and negative) for everything.

Mind you, LTC is more than frame accrate. As it has a specific start / end of the bits in one frame, its possible to sync up to some 2 milliseconds. The display / visual slate TC should be no more than a last resort.

 

hth,
Bouke

 

Link to comment
Share on other sites

  • 5 months later...
On 6/23/2022 at 7:49 AM, Bouke said:

Mind you, LTC is more than frame accrate. As it has a specific start / end of the bits in one frame, its possible to sync up to some 2 milliseconds. The display / visual slate TC should be no more than a last resort.

Hi Bouke, how is measured LTC precision? You write the position of the sync word can be localized within 2 ms... Is this a ball park estimate or can it be measured?

 

merci!

Link to comment
Share on other sites

Of course it can be measured, but it highly depends on the software / algorithms / sample rate to define 'how' accurate it is.

You also need to take into consideration how accurate your reference clock is, or if you take the signal itself as being the clock.
Then, how accurate is the signal itself? (It could jitter a bit.)

 

 The exact position of the sync word (the end of it) is defined by the end of the last bit. That is, in audio terms, a polatity change. (End of a block of the blockwave)
If you don't write any 'smart' algorithm around it, that is thus as accurate as the sample rate used to digitize the signal.
In case of 48Khz, that means 1/48000 of a second, and that is way more accurate than 2 ms of course.
But, jitter, latency etc will mess things up.
(Note, dedicated hardware probably will not 'sample sound', just see high/low changes and clock on that.)

But why do you ask?

 

 

Link to comment
Share on other sites

Of course thanks for your repply

 

On 12/1/2022 at 4:17 AM, Bouke said:

If you don't write any 'smart' algorithm around it, that is thus as accurate as the sample rate used to digitize the signal.

 

so one as to detect zero crossing of the last bit, which is influenced by the slew rate of recorders analog front end (don't they all have DC blocking caps? Or automatic gain control?)... indeed the error is way more than the sync track sample period (sampled or not, implicit zero-crossing detection is hard, hence the tri-level stuff). So your 2 ms is an estimate (a sensible one), but not an actual experimental measure with your tools  (I'm not nitpicking, just making sure I understand what I'm reading)

 

On 12/1/2022 at 4:17 AM, Bouke said:

But why do you ask?

 

I've developed a novel AUX audio syncing track format, useful for experimental scientists who do recordings on multiple devices but aimed also at Indy film productions in need of low cost TC solutions  Yes, i know

 

I ditched SMPTE LTC from the start because my tests showed that biphase mark encoding is greatly degraded by acoustical coupling: I wanted it to be functional even on point and shoot cameras without mic input, call me crazy... 🙂

 

The software/device combo can achieve synchronization of two recordings within 0.083 ms (measured, not estimated).

 

I wouldn't have done it without the incredible work of the FOSS community (python language devs, python modules writers, ffmpeg maintainers, Arduino team, Adafruit, etc...) so I'm giving back and the tools will be open sourced too! No commercial product is planed, and some soldering will be required...

Link to comment
Share on other sites

16 hours ago, lutzray said:

so one as to detect zero crossing of the last bit, which is influenced by the slew rate of recorders analog front end

No clue how much, but LTC 'should' have a low pass filter applied to help here. I don't think it's a big issue.
 

 

16 hours ago, lutzray said:

don't they all have DC blocking caps? Or automatic gain control?)

DC blocking, probably all, acg, varies, but that also should be no issue at all, in both LTC and IRIG the gain is not important. IRIG will have no fight with a DC blocking system, LTC 'could', but I have never seen it.
(DC blocking should not be an issue, or AC / DC would not sound well. A distorted guitar is a blockwave : -)


 

 

16 hours ago, lutzray said:

sampled or not, implicit zero-crossing detection is hard

 

Why? At 48000 Hz you would be as accurate as 0.02 milliseconds, and with (to keep it simple) oversampling (like for true peak finding) you could get 4 times more accurate. And then you could do some math if you have the exact framerate and average things out, to get even further accuracy.

My 2 ms is a guess. I have no means of real world testing. I can test my own software generated files, and then I indeed get a 0.02 millisec accuracy, but that has nothing to do with real world.
(What my routine does is generating lists with sample values and sample positions, omitting those if no zero has crossed, then find bits, then find syncword, and thus the exact sample of a new LTC frame is known.)

I don't bother with oversampling, although it won't be difficult, the theoretical 0.02 ms is more than enough.

While we're talking about this (fun stuff imho), others are talking about phase issues between boom and mic.
Keep in mind, I am NOT an audio engineer, but some math:
To get two mics 'really' in sync, sound must arrive at the same moment.  Assuming a very close boom and a lav, there is still 30 cm of difference.
Sound travels at 300 m/s, so 0.3 / 300 = 0.001 = 1 ms offset already.
(I can't understand how you could ever work out all phase issues, as each frequency has it's own wavelength thus different phase angle, and sound never comes from one direction / source alone, but that's another issue.)


I don't bother with more accuracy, nor with exact measurements, as the typical cheap cams / setups involved introduce so much 'unexpected' that it is 'good enough'. (And I provide an user custom offset, if the offset is constant (which, funny enough in a digital world, not always the case.)

Then, the high accuracy for syncing sound to picture ONLY is possible if the end user either lets me render new video files with audio embedded, or changes the BWF timestamp.
BUT, stupid enough, EVERYONE changes the video TC to match the LTC, instead of altering the audio timestamps,  thus rounding the found values to whole frames, introducing a potential 20 msec error, instead of 0.02 msec accuracy.

(Still good enough for rock 'n roll most of the times, but that's beside the issue.)


 

16 hours ago, lutzray said:

I've developed a novel AUX audio syncing track format,

 

Fun!

Can you point me to the project?

 

16 hours ago, lutzray said:

useful for experimental scientists who do recordings on multiple devices but aimed also at Indy film productions in need of low cost TC solutions 


For science, I can totally understand it. For Indy, please don't, as even the simple LTC workflows cause enough trouble already. Of course there will be a few smart kids who get it running, but it won't be for the masses.
Issue remains that you need to insert some params for your recording devices / setup (wireless introduces delay), but for measuring delta T it probably always works.


What I don't understand (not knowing your signal encoding / error handling / checksum yadda), how does it come that you are only 0,083 ms accurate?
(Yeah, of course if you have a boom box on set and let the cams walk around without position info, it  will be hell, but even that could be worked out with two boom boxes and Pythagoras : - )
 

16 hours ago, lutzray said:

so I'm giving back and the tools will be open sourced


Thank you!
(I wish I could do more open source, but I'm fighting for a living already. I can give you a better Python Timecode module than the current one on pypi, that is filled with bugs (eg, it floors values instead of round them, resulting in being off by a whole frame every now and then.)
 

Link to comment
Share on other sites

On 12/3/2022 at 4:42 AM, Bouke said:

Of course there will be a few smart kids who get it running, but it won't be for the masses

 

Indeed, and that's by design: It will not be a finished product, the aimed community is "1 man DIY production crews" with soldering skills, with a zest of IT literacy. Not many people, I confess 🙂

 

On 12/3/2022 at 4:42 AM, Bouke said:

I wish I could do more open source, but I'm fighting for a living already

Sorry to learn this... is this related to the movie industry or related to the tanking EU economy  (thanks to NATO-BRICS proxy wars)?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...