8000 jltcntp - needs protection from Jack XRUN · Issue #22 · x42/ltc-tools · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

jltcntp - needs protection from Jack XRUN #22

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
mungewell opened this issue Jul 29, 2020 · 6 comments
Open

jltcntp - needs protection from Jack XRUN #22

mungewell opened this issue Jul 29, 2020 · 6 comments

Comments

@mungewell
Copy link
Contributor

Since 'we' are receiving a continuous stream of audio data we are likely(?) to experience an XRUN from time to time.

The LTC frame is not protected, so a missing section of audio could mean that 2 part frames could be interpreted as one to produce incorrect data.

Write up and fix in process.
@x42
Copy link
Owner
x42 commented Jul 29, 2020

Depends on your hardware and system. pro-audio systems can be tweaked to run reliably (zero x-runs) at sub millisecond latency. -- While some casual consumer systems have issues to with even 20-30ms periods.

If it's important to you, Implementing some x-run recovery or gracefully handling discontinuities (flywheel) may be prudent.
Then again you are better off to prevent the x-run in the first place.

@mungewell
Copy link
Contributor Author

Agreed, no xruns would be better.... but I already wrote some code ;-)

With SyncIO driving Digi888's word clock with SPDIF output fed via M-Audio USB sound card, I got 3 xruns in a 8hr (overnight) session.

@mungewell
Copy link
Contributor Author

Example output, with faked xrun. Note how you 'loose' a few timecode frames

00-00-00 +0000 03:17:59:27
00-00-00 +0000 03:17:59:28
00-00-00 +0000 03:17:59:29
00-00-00 +0000 03:18:00:00
00-00-00 +0000 03:18:00:01
00-00-00 +0000 03:18:00:02
Restarting LTC decoder: Wed Jul 29 12:36:17 2020

00-00-00 +0000 03:18:00:05
00-00-00 +0000 03:18:00:06
00-00-00 +0000 03:18:00:07
00-00-00 +0000 03:18:00:08
00-00-00 +0000 03:18:00:09

@mungewell mungewell mentioned this issue Jul 29, 2020
Closed
@mungewell
Copy link
Contributor Author

Now I am observing XRUNs I am seeing a shift in the time continuum. I an not (yet) understanding why.... please hold on implementing patch until I figure out why.

Note: this only occurs with real XRUNs, but not when I create a fake one....
restart_glitch

restart_glitch_mon

@mungewell
Copy link
Contributor Author

May have found the reason for the XRUNs, from the "Fast Track 'not-so-pro'" manual.... guessing that there is a slight difference in SyncIO's clock rate.
fast_track_pro

Time to MOTU up I guess. :-)

@dimitry-ishenko
Copy link
Contributor

I agree with @x42 that XRUNs should be handled outside of the scope of this tool.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@x42 @mungewell @dimitry-ishenko
0