On 6/14/2012 3:15 AM, Clemens Ladisch wrote:
As long as you have 2 periods or events per 179s, the wrap-around can be detected without any issues. It's explicitely handled in the code.
AFAICS there is no code that enforces the 179s restriction.
179s corresponds to a 33MB buffer for stereo 48kHz 16bit. There is indeed nothing preventing the wrap-around at the moment but this could be achieved by limiting the buffer size.
And why are you using a separate wallclock timer instead of the sample count? Does the higher resolution result in a noticeable improvement?
The wallclock is common for each HDAudio controller, this helps you build _one_ estimator for the drift between audio time and system (monotonic) time. It'd help avoid what PulseAudio does today, ie a different drift estimate per sink/source. If you work with sample counts, you'll have separate results for each devices and possibly different ASRC in user-space. Also the precision of sample counters is limited to 10us for 48kHz, a lot higher than what we can get with PTP-based schemes. The accuracy of the wall clock is 41.6 ns, order of magnitude more precise.
How should userspace detect streams whose sample clock is not synchronous with this wall clock, such as digital inputs?
Good point. I didn't think about this case, i need to look into it. Thanks for your feedback, much appreciated -Pierre