the HVR-1600 card was recording very loud static for "audio" tonight.
Well, it hasn't failed again since that incident, but we haven't fixed anything yet either.
Andy Walls came up with some new rewrites of the driver code to try, but they still need some work -- he doesn't have regular access to OTA analog to test with (he lives in europe, I believe), which makes it somewhat difficult for him.
Meanwhile, I'm trying to apply some logic to the problem.
See.. Andy is working on the assumption that the current code must be doing something wrong, so he is producing changes to how the current code does things.
But.. my observation is that the current code works perfectly well 50-80% of the time, which means that it is doing things correctly. Just not consistently.
There's a difference.
The lack of consistency strongly suggests race condition
to me. So I've been exploring that angle of things for the past week, trying various low-level tricks I've learned from 18 years of Linux kernel work.
This did turn up a pair of bugs in the driver today, and I've patched those out of existence. One of them could
be the problem here, but I don't think so.
However.. back to the race condition
theory. There are a number of levels at which races can occur.
- Between the host computer and one of the microcontrollers on the HVR-1600 board.
- Within the host software (driver) itself.
- Between the host CPU and the PCI interface of the HVR-1600.
It's that last one which is now ringing alarm bells for me here. See, the driver has code all through it to perform "retries" when writing registers on the card, because apparently a register write doesn't always work first try.
That information suggests a possible issue with PCI write ordering/combining. So I've patched my copy of the code here to prevent such issues, and we'll see how things go with just that one fix in there.