This application note describes a method to receive analog timecode from an external source. For simplicity I use a USB analog soundcard that i plug in to the blocks server. Such audio interface should be "class compliant" USB-A, that means to special driver is required for the device to operate basic functionality properly.

I refer to the analog input on the Blocks server in the article, the application can run on any linux computer, so if your source signal is elsewhere it may make sense to pickup the sync signal with another computer running the LTC_timecode reader software. One way of doing that is to use the blocks server image to create the computer. Disable the blocks service and then follow the instructions in this application not to make this into a LTC timecode reader device.

Plug in the USB audio device to the blocks server. Use a second computer to play some sample LTC timecode, just for testing purposes. I just play the sample audio in my Windows laptops mediaplayer. Plug an 3.5mm audio cable between the computers audio output with the line in/mic input of the analog audio card of the Blocks server.

To capture the desired device we must figure out the ALSA name of the usb-device. To do so we open the terminal as the pixi-server user and type:

aplay -l

Look for an entry like:

plughw:CARD=Device,DEV=0
    USB PnP Sound Device, USB Audio
    Hardware device with all software conversions

The ALSA name is

plughw:CARD=Device,DEV=0

If you have more than one USB audio device one can expect the next one to be named:

plughw:CARD=Device_1,DEV=0

and so on.

To test if we get any signal one can now plug in headphones in the USB card output and make an Echo test:

arecord -D plughw:CARD=Device,DEV=0 -f cd | aplay

You should hear the incoming timecode in the headphones. Stop the echo test by hitting ctrl+c.

Now we can dryrun also the LTC reader software by making it log the time using the -t parameter. Change to the directory where the software is stored, on a Blocks server image is is stored in home/blocks/native/

cd native

Run the program using the -d parameter to specify device and -t parameter to run in test mode.

./timecode-reader -d plughw:CARD=Device,DEV=0 -t

We should see the time changing as the time source progress in the console output:

New settings: i/2000/t/25/p/1633/n/1/c/0/w/150/f/2
01:57.11 signal, dbFS: -0.6

In test mode we may also see some error logging while reading the signal, this is normal.

Non contiguos 92925 with lastAccepted 92929
Minor error ignored. 92926 contiguous with lastReceived 92925

There are a few steps to do before we can make use of the incoming analog timesource in blocks.

The driver to handle the timedata from the LTC-reader software is not enabled by default. To make a driver enabled one must make sure the driver files exist in the script/driver directory in the PIXILAB-Blocks-root. The TimecodeLTC driver are stored in the script/driver-archive/ directory and needs to be enabled:

Change to the script directory:

 cd /home/blocks/PIXILAB-Blocks-root/script 

Move the driver files to the drive directory:

 mv /driver-archive/TimecodeLTC.ts /driver-archive/TimecodeLTC.ts driver/

Restart the blocks server:

systemctl --user restart blocks.service

The driver is now available to use on network devices.

Under the page Manage/Network we set up a new device and assign the TimecodeLTC driver. The ports is predefined in the driver to match the default configuration to the Timecode reader on the server.

Create a timeline block, it can be left empty for testing purposes. Set the timeline to use External synchronization in the timeline settings. Select your LTCTimecode device as sync source property.

Apply any time offset as required. This timeline is now controlled by the timecode.

To make the timecode reader autostart we must perform a few more steps. On a blocks server we have prepared whats called a unit file used by systemd in most linux distros to manage running programs and services.

Change to the users unit files directory:

cd /home/pixi-server/.config/systemd/user

Edit the timecode-reader.service.config file.

nano timecode-reader.service.config

Edit the TIMECODE_READER_OPTIONS= line to make the software use the wanted device name. In my case I set it to:

TIMECODE_READER_OPTIONS=-d plughw:CARD=Device,DEV=0

Next step is to enable the service at computer startup.

systemctl --user enable --now timecode-reader.service

If we want to read more than one LTC timesource we would typically need to duplicate and change the unit files in order to be able to do so.

We can rewrite the example unit file into a unit template to do this.

Rename the unit file like this:

mv timecode-reader.service timecode-reader@.service

Edit the unit template.

nano timecode-reader@.service

Use this config:

[unit]
Description=LTC Timecode Reader (%i)

[Service]
EnvironmentFile=%h/.config/systemd/user/timecode-reader.%i.config
ExecStart=%h/native/timecode-reader $TIMECODE_READER_OPTIONS
TimeoutStopSec=20
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

Rename the config:

mv timecode-reader.service.config timecode-reader.alpha.config

Make as many copies as you want instances:

cp timecode-reader.alpha.config timecode-reader.beta.config

Edit the config files as in the single instance case above. Make sure to specify a different udp port on all the subsequent instances.

nano timecode-reader.service.beta.config

# Options to pass to the timecode-reader program, e.g.,
# TIMECODE_READER_OPTIONS=-d "Alsa device name"§ -p "UDP port"
TIMECODE_READER_OPTIONS=-d plughw:CARD=Device_1,DEV=0 -p 1634

Efter any unit change make sure to reinitizialize systemd daemon:

systemctl --user daemon-reexec  # Just in case you've changed the template
systemctl --user daemon-reload 

Enable (autostart) and start the two instances

systemctl --user enable --now timecode-reader@alpha.service
systemctl --user enable --now timecode-reader@beta.service