Re: [Jack-Devel] fractional frame rates for alsa_in and alsa_out

On Monday 13 June 2016 19:34:07 Fons Adriaensen wrote:
> On Mon, Jun 13, 2016 at 12:04:30AM +0200, Markus Grabner wrote:
> 
> > 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.
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

* Attachment: 'zita-exact-rate.patch'
content-type: text/x-patch
* Attachment: 'zita-jacktime.patch'
content-type: text/x-patch

1471553210.28318_0.ltw:2,a <23372690.oO6qnTj5MI at mark>