On Sun, 2010-06-27 at 10:46 -0400, David Dillow wrote:
On Sat, 2010-06-26 at 18:04 -0400, David Dillow wrote:
When using a timing voice to clock out periods during capture, the driver would slowly loose synchronization and never catch up, eventually reaching a point where it no longer generated interrupts.
This has survived overnight testing at 44.1 kHz/16 bit/mono without issue.
Only to die at 12 hours and ~15 minutes. It did not trip any of the instrumentation I was using to verify operation, so this may be a different problem. I'm looking into it.
Ok, definitely different problem, as it dies 12:15 into a run using 2 periods per buffer, so the virtual timing code does not come into it. Interestingly enough, it died after ~44092 seconds while recording at 44100 Hz.
The patch should be applied. If and when I find the source of this new bug, I'll submit a separate patch.