18 Aug
2016
18 Aug
'16
3:46 p.m.
On Monday 13 June 2016 19:34:07 Fons Adriaensen wrote:
On Mon, Jun 13, 2016 at 12:04:30AM +0200, Markus
Grabner wrote:
Thanks for the hint! It took me quite a while,
though, to get these programs to work properly, for two reasons:
1.) Out of the box, zita-a2j/j2a wouldn't start at all with my device since no exact
(integer) frame rate could be set. I therefore did the same exercise as with alsa_in/out
to support fractional frame rates (see attached file "zita-exact-rate.patch"). I
hoped it would also converge faster to the correct frame rate if a correct initial value
was given, which I could indeed observe occasionally, but on average there was no
difference in convergence time. At least the error displayed in verbose mode now exactly
represents the relative error between the internal clock sources of both devices :-),
which is reasonably small.
2.) After having fixed the initialization issue, I noticed that after a couple of minutes
zita_a2j/j2a stop working with the message "Detected excessive timing errors, waiting
10 seconds." and would not recover from this. I added some additional debugging
output and tracked this issue down to the point that the problem occurs immediately after
the internal timer (lower 28 bits of the jack timestamp) overflows. Therefore I modified
the code such that the full 64 bit jack timestamp is used wherever possible (see attached
file "zita-jacktime.patch") to get rid of overflow issues (well, almost, the
jack timer overflows after more than half a million years :-).
Could you please review the patches and let me know what you think about these?
Thanks & kind regards,
Markus
A while ago I initiated work on a Linux driver
for Line6 devices
(now under sound/usb/line6 in the Linux kernel tree). Some of these
devices have weird sample rates (39062.5Hz, derived from the 10MHz
USB clock divided by 256). The alsa_in and alsa_out jack clients
are convenient tools to use such Line6 devices together with more
standardized hardware operating at, e.g., 48kHz. However, alsa_in
only supports integer sample rates, and even after a couple of minutes,
alsa_in doesn't detect the correct resampling factor 1.2288 (48000/39062.5),
but still reports the initial approximated value 1.228816 (48000/39062).
Admittedly, the error isn't too big, but is larger than the error of
high-quality crystal oscillators. And, after all, why use an approximation
if we know better?
You could try zita-a2j and j2a (which are also provided by Jack1 as
internal clients) - they should have no problem syncing.
Anyway, the small initial error doesn't matter at all since these
programs will sync to the *actual* sample rate. The nominal value
is just a starting point, and the rounding error (approx 0.0013%
for your example) is much smaller than the random error that can
be expected between any two devices.