We have seen the same sort of problem that Doug reports for USB devices
with PCI sound cards when the recording CPU is heavily utilized. As he
suggested, I suspect the problem is that the CPU is so busy doing other
things that it doesn't have time to process some of the incoming audio
data before they are no longer available.
As far as I know, there is often no way for an application to detect
dropped samples other than to try to compare the number of samples it
has received during a recording to the number expected given the
purported sample rate. Unfortunately this is usually not very accurate,
especially over shorter time periods, since it's not possible to obtain
either the precise duration of a recording or the precise number of
samples that a sound card has converted. For example, it may not be
possible for an application to account for samples buffered on the sound
card, in its driver, in the host operating system, and/or within an
audio API.
We have also seen a recording duration computed from the number of
samples received and the purported sample rate differ from real time at
a small but roughly constant rate, even when the recording CPU is
lightly utilized. I suspect that this is due to small inaccuracies in
the A/D clock.
Harold Mills
Bioacoustics Research Program
Cornell Lab of Ornithology
|