Timeline on very long recordings faster than real time

[GTBecker]

I record bats overnight producing a continuous stereo track that is 10 or 12 hours long. Audio originates at a Diamond XS71HDU at 192kHz on a WiFi'd RaspberryPi2 (Raspian) which sends an .ogg stream to my desktop machine. As best I can determine there are no irregular samples in the stream.

At my desktop, I start and end each Audacity recording with a track label of the precise UTC time. This results in an Audacity timeline about an hour faster than the actual elapsed time, on the order of 10% fast. Can anyone suggest where to start troubleshooting this error?

Raspian Linux RPi2 3.18.10-v7+, Audacity 2.0.5 on LMDE1 UP8, current.

Thanks.

Tom

[Gale Andrews]

What is your input device in Audacity's Device Toolbar? If it's "pulse" you may need to change the pulse configuration files to default to 192000 Hz, or use the (hw) input choice instead.

Dose the Diamond have a control panel for sample rate? You should look there too.

Gale

[cyrano]

Since the Raspberry Pi doesn't have an internal clock chip, that kind of drift on a very long recording is to be expected, I'd think.

[GTBecker]

... Pi doesn't have an internal clock chip...

Hmm. What is the timebase of the Audacity timeline?

I've assumed it is tSec=(samplecount*samplesize)/bitrate? It's hard to accept that the Diamond's 192kHz is 10% off - but looking at vorbis's status the average bit rate displayed is "-2". Is that a hint?

Tom

[cyrano]

I have no idea what the basis of the timeline in Audacity is.

A lot more about problems with audio on the Raspberry here:

https://hifiduino.wordpress.com/2014/11 ... tal-audio/

Problem number one: the internal 19 MHz CPU clock isn't really suited for audio. That might not be your problem, but it's part of the complexity.

The page I cited is talking about output, not input, but will give you some idea about the problem.

Problem number two: the USB implementation on the Pi.

Since they are talking about DAC's and not about ADC's, it isn't exactly the same problem, but again, you'll understand why everything also plays in a recording environment.

10% off seems like a lot. There are reasons why professional sound gear is so much more expensive. Clocks is just one of them. In a professional setting, you often need to sync several ADC's. And that's why a separate external audio clock is often used. To avoid the problem before it surfaces. Hec, there are even high end clock generators that don't do anything but generate the master clock for the studio.

A very simple way to cut back on drift, is maker shorter recordings. I don't know if that is an option?

Another solution could be to use a dedicated bat mic, like the Italian Dodotronic...

http://www.dodotronic.com/

And even here, they seem to have abandoned USB mics. They used to have this:

http://goedgeluid.be/Dodotronic-ultrasone-USB-mic.html

[Gale Andrews]

looking at vorbis's status the average bit rate displayed is "-2".

Where are you seeing that?

Recording speed problems are relatively common if you choose pulse and will occur if sample rates are mismatched anywhere, so I still think that should be one of your lines of enquiry.

Gale

[steve]

Hmm. What is the timebase of the Audacity timeline?

The time is calculated from the sample count.

Example:
If the sample rate is requested at 100,000 samples per second, then Audacity will position the samples at intervals of 0.01 ms.

My guess at what is happening is that some samples are being dropped ("xruns") due to the equipment being unable to keep up with the data.
Taking the above example. If the equipment is dropping one sample in 10, then in 1 second you will have 90,000 samples spaced at intervals of 0.01 seconds (Audacity still expects the sample rate to be 100,000 samples per second). Thus in 1 second Audacity only receives 0.9 seconds of audio, so the track will be too short. In other words, the audio will be 10% too fast.

There are some tips for minimising xruns on Linux here: http://wiki.linuxaudio.org/wiki/latency ... zing_xruns

[GTBecker]

... USB implementation on the Pi...

Yes, that was a problem. I have a good deal of experience with the Pi and its USB ills of the earlier versions, but the Pi2 has cleaned that up pretty well. Still, one of my streams (a VLF receiver for lightning and spherics fanatics) is served by an original Pi that has been running for 90+ days since the last boot without any apparent problems. It uses a CM6206-based USB module running at 48kHz, filtered and resampled to 32kHz mono. Audacity is not a part of that process. http://78.46.38.217/vlf9

There are several ultrasonic mics on the batting market; today, most bat recordists successfully use USB mics - but most also are cabled directly to a laptop or tablet that runs bat-specfic recording and analysis software. I do remote recording; the Pi2 is out there where the bats are (and where I don't want to spend the night), solar charged, battery powered. The WiFi link is my cable. At the moment the remote package is on a dock not far from my home (http://78.46.38.217/amb9) but the link has been a mile long at one location. The Pi2 package actually serves two streams, one of which is downshifted 10kHz (http://78.46.38.217/amb9u).

... vorbis: average bit rate: -2...

This is reported at the receive end of the WiFi link which moves a 96kHz stereo stream to a fast quad-core laptop.

> ... time is calculated from the sample count...

That's rational and good to know.

Thanks for your thoughts so far guys. I'll try a few things to localize underruns, although I don't see any reported.

Tom