This magically didn't really affect normal operation, because in
normal operation the demodulator can consume data faster than it
is produced, so the fifo never grows beyond 0-1 items.
However in cases where the demodulator is slow and the producer
is fast (e.g. reading from a file and running with lots of debug on)
the fifo would lose buffers as soon as it had more than one pending.
It was possible, due to an off-by-one error in normalize_timespec, that
the computed deadline passed to pthread_cond_timedwait had tv_nsec == 1000000000.
glibc would reject this with EINVAL. While I never caught this in the act, there
seem to be two follow-on problems from this:
1) we were looking for a negative return from pthread_cond_timedwait and testing errno.
This is not how errors are reported, instead pthread functions return the error value
directly. So the enclosing loop could spin forever, repeatedly passing the bad deadline
value.
2) even if the error handling caught the EINVAL return, it assumed that the mutex was
no longer held and didn't release it; but on error returns, the mutex state is actually
untouched.
Fix both cases (probably), and log about unusual returns from pthread_cond_timedwait
Update all the SDR implementation to use it.
This was getting pretty ugly with code getting copy&pasted in all the SDR
implementations. Unify it all and give it a simpler API. Linked list works out
much simpler than the circular buffer. Also, simplify copying the overlap region
around by just using a separate buffer (it's only a few hundred bytes long, so
the double copy is not a big deal).
Oliver Jowett