I've run into [an expected] problem in my attempts to write a simple
recording application for a Poor Man's Multitrack Recording PC.

The setup is this...

One PC with several USB audio devices attached. The software opens all
devices and begins recording.

Simple setup...complex problem.

Obviously there is a block alignment problem with this setup because I
can't guarantee all devices start recording at the same moment in time.
I can correct for this post-record by time-shifting the tracks to get
them to align. No problem.

The bigger problem is that the devices are not synchronized to the same
clock and there is a drift in the alignment across all devices. (They
are cheap devices, hence the PMMR-PC title.)

So, my question is this...

Has anyone run into this problem before and solved it in software, or
has anyone seen this problem addressed before (in White Paper form,
etc.)?

My simple little brain considers solutions like attemping to time the
block reads and adjust the data from N-1 devices to match a random
reference device. However, getting timings correct enough that drifts
over time on the order of hours is problematic.

Thoughts?


Paul Braman
PauldotBramanatNielsenMediadotcom
Senior Engineer
Nielsen Media Research

"Paul Braman" wrote in message
oups.com
I've run into [an expected] problem in my attempts to write a simple
recording application for a Poor Man's Multitrack Recording PC.

The setup is this...

One PC with several USB audio devices attached. The software opens
all devices and begins recording.

Simple setup...complex problem.

Obviously there is a block alignment problem with this setup because I
can't guarantee all devices start recording at the same moment in
time. I can correct for this post-record by time-shifting the tracks
to get them to align. No problem.

The bigger problem is that the devices are not synchronized to the
same clock and there is a drift in the alignment across all devices.
(They are cheap devices, hence the PMMR-PC title.)

How long does it take a a drifting source to drift off so badly that it
needs correction?

So, my question is this...

Has anyone run into this problem before and solved it in software, or
has anyone seen this problem addressed before (in White Paper form,
etc.)?

In proper audio production environments, the equipment clocks are slaved,
and/or are correct enough that they don't drift off ever, or at least not
very fast.

My simple little brain considers solutions like attemping to time the
block reads and adjust the data from N-1 devices to match a random
reference device. However, getting timings correct enough that drifts
over time on the order of hours is problematic.

The usual circumvention is to split the drifting track periodically, and
nudge each piece back into synch.

"Arny Krueger" wrote in message
news
My simple little brain considers solutions like attemping to time the
block reads and adjust the data from N-1 devices to match a random
reference device. However, getting timings correct enough that drifts
over time on the order of hours is problematic.

The usual circumvention is to split the drifting track periodically, and
nudge each piece back into synch.

A better post solution is to measure the number of samples in each file, and
resample so they are all the same. The wave headers must be altered to show
the same sample rate. Voxengo R8Brain is excellent for this, and is
freeware.

A much better solution though is to use a multichannel box in the first
place!

TonyP.