Re^2: Time::HiRes (un)reliability in Windows/Cygwin ??

Thanks for the info -- esp. about the version issue (I'll need to check into that, but the machine is not close to my desk).

I also tried a one-liner test similar to what you showed, and I got results similar to yours -- that is, I was not able to replicate the problem when I tried the simplest possible means to demonstrate it.

Naturally, the overall situation is more complicated -- the script that is writing the log file is actually a Perl/Tk app (so that the phrase to be read aloud is presented in a nice big font), and so far I'm just assuming that the sampling rate of the audio file is "accurate" (supposed to be 16 kHz, though I'm not sure if this is done via downsampling from something like 44.1). Uncertainty abounds...

Comment on Re^2: Time::HiRes (un)reliability in Windows/Cygwin ??

Replies are listed 'Best First'.
Re^3: Time::HiRes (un)reliability in Windows/Cygwin ?? by almut (Canon) on Jul 26, 2007 at 00:19 UTC
so far I'm just assuming that the sampling rate of the audio file is "accurate" It might be worth verifying that. What audio recording hardware are you using? In fact, there are some particularly bad soundcards out there, like this one, for example, which could approximately account for the drift you're observing... Most cards are significantly better, though (by orders of magnitude), so this may not necessarily be the problem in your case. But how would you know, unless you've actually measured it...? A relatively easy way to check would be to record the ticking of a reasonably accurate clock (with an analog display), and then verify that the peaks of the recorded waveform stay in sync with what the audio software reports based on the assumed sample rate. (Even cheap quartz wrist watches typically have of drift of less than one second per day, so that should be a sufficiently precise time reference for the purpose at hand...) Incidentally, when I was working in psycholinguistic/ERP research, we were using similar experimental setups, to present stimuli, and such... And from those experiences I can confirm that sample rate inaccuracy can in fact become a problem in special cases like the one you're describing. That was more than a decade ago, though. Hardware might actually have improved since then — or maybe not...	[reply]

Replies are listed 'Best First'.

Re^3: Time::HiRes (un)reliability in Windows/Cygwin ??
by almut (Canon) on Jul 26, 2007 at 00:19 UTC

so far I'm just assuming that the sampling rate of the audio file is "accurate"

It might be worth verifying that. What audio recording hardware are you using? In fact, there are some particularly bad soundcards out there, like this one, for example, which could approximately account for the drift you're observing... Most cards are significantly better, though (by orders of magnitude), so this may not necessarily be the problem in your case. But how would you know, unless you've actually measured it...?

A relatively easy way to check would be to record the ticking of a reasonably accurate clock (with an analog display), and then verify that the peaks of the recorded waveform stay in sync with what the audio software reports based on the assumed sample rate. (Even cheap quartz wrist watches typically have of drift of less than one second per day, so that should be a sufficiently precise time reference for the purpose at hand...)

Incidentally, when I was working in psycholinguistic/ERP research, we were using similar experimental setups, to present stimuli, and such... And from those experiences I can confirm that sample rate inaccuracy can in fact become a problem in special cases like the one you're describing. That was more than a decade ago, though. Hardware might actually have improved since then — or maybe not...

[reply]