From: Jonathan W. <jw...@ph...> - 2007-07-26 23:26:03
|
Hi Pieter > > Ok, I managed to grab 10 minutes last night to test svn496. The MOTU code > > suffered from some compile errors due to the timestamp type changes (which > > have hacked workarounds svn 497) but that aside I'd give a verdict of > > "promising". The MOTU ran, seemed to start cleanly and didn't loose sync > > within the first 10-20 seconds of running (I didn't have time to test > > longer). There was one regression: it seemed that every period (or at the > > very least quite a few of them) prompted a "rather large" warning from > > incrementFrameCounter() with a corresponding glitch in the audio output. > > However, I didn't get a chance to investigate this - it could for example be > > a consequence of my quick-and-dirty hacks for the MOTU stream processor code > > mentioned above. I should get some more time on this tonight so I'll > > provide more details in due course. > That all sounds very good. SVN revision 498 is up now. This contains the usual hacks around the MOTU code for my debugging, a neater solution to the ffado_timestamp_t/float issue within the MOTU code plus a change in the type of ffado_timestamp_t from float to double. After investigating time drift and course timestamp jumps (which is what was causing the MOTU's glitches) it became apparent that the root cause was in fact a lack of precision in the accumulators and the TimestampedBuffer's timestamps themselves. Because we run the timestamps in ticks and wrap only after 128 seconds, there simply isn't sufficient precision in a float to keep track of the timestamp. In short, there are 24576000 ticks per second. At the 50 second point (for example) the tick value is therefore 1228800000 (3145728000 at 128 seconds). In other words, there are 10 significant figures just for the units part of the timestamp. Tests with the MOTU and my simulations have shown that at least a couple of decimal places are needed if the DLL is to track the device to the required accuracy, so this demonstrates that we need about 12 significant figures if things are not to drift (preferably a few more). A float has no more than 9 significant decimal places. With the change in type from float to double I found that the MOTU would lock sync and remain stable for quite some time (I think the longest I tested was 30 seconds, but even that's more promising than other tests in recent weeks). Based on all this I think we're going to have to use doubles for ffado_timestamp_t, which is what revision 498 does. > > One thing this did point out was that addTicks(), subtractTicks() and > > friends are still expecting int64_t timestamps. I suspect that all these > > need to be converted to ffado_timestamp_t as well so they are consistent > > with the type used for the actual timestamp. I will probably do this > > first up since I suspect this type mismatch (and the inherent rounding which > > results) may be part of the MOTU's problem. > I would like to keep the xxxTicks() functions with uint64_t since they > are specific to the 1394 cycle timer (hence cycletimer.h). There are > more places in that file where that assumption is made (e.g. the > wraparounds are at 128sec). > > If we need similar functions for the timestamped buffer we should > implement them there (if not already done). Sure. As a result of my tests last night I no longer believe the xxxTicks() functions need to work with floats. > >> However for my setup it seems to be impossible to use a framerate other > >> than 48000 or 96000, and it also doesn't seem to like a setup with an > >> external sync'ed card. > > > > My tests were at 44k1. Things weren't perfect but at least it ran (albeit > > with audio glitches). Is this what you meant by it being "impossible to use > > a framerate other than 48000 or 96000", or were your issues somewhat more > > terminal? I will try at 48k myself and see what happens, but I suspect much > > the same behaviour given the way the MOTU works. > It meant complete chaos for me. Based on my tests last night and findings regarding precision I think it would be worthwhile for you to test 44k1 again using svn revision 498. The bebob devices work a bit differently to the MOTUs, and because 48k is a factor of 24576000 the lack of precision may not have been a factor for you with 48k rates. However, since 44k1 is not a factor of 24576000 the truncated precision could easily have lead to inaccurate timestamp prediction, which in turn sends the rate right off. Regards jonathan |