Re: [linux-audio-user] Common linux audio layer

From: Mark Knecht <markknecht@email-addr-hidden>
Date: Sun Jan 16 2005 - 21:22:57 EET

On Sun, 16 Jan 2005 12:19:01 -0500, Lee Revell <rlrevell@email-addr-hidden-job.com> wrote:
> On Sun, 2005-01-16 at 08:41 -0800, Mark Knecht wrote:
> > The ONLY REAL-TIME solution to this problem is for the two machines
> > to be synced somehow so that they run at the exact same frequency.
> > Some high-end consumer audio equipment is including expensive hardware
> > for doing this via 1394 interfaces, as do some high-end sound cards
> > via Word Clock, ADAT, spdif or other interfaces.
>
> Microsoft claims that the audio system in Longhorn solves this problem.
> It looks like their solution requires driver & hardware support for
> mmaping (aka very fast access from userspace) the wall clock and
> position registers, then they correct for the drift. Of course this
> certainly involves resampling everything in software.
>
> Anyway it's an interesting read.
>
> http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/WaveRTport.doc
>
> Lee
>

Humm....51 pages and Open Office doesn't have a feature to scale the
document to fit my screen. Painful.

Anyway, you're right, it looks like something I should go through in
more depth. I just skimmed it very quickly and ran into the comment
'WaveRT-compatible audio device' making me think that M$ is going to
push new hardware capabilities to take advantage of this. That's fine,
but it may mean these capabilities are limited to future devices and
not the ones we already have.

I'm still not clear how the problem or crystal ppm would ever be dealt
with. I've messed a bit with this (when I was employed...) doing 1394
chip design. No 2 crystal oscillate at the same frequency, and even
when you buy highly tuned crystals (say +/- 50ppm) the frequency of
oscillation changes over time and temperature. The system using the
crystal doesn't know it's exact frequency though. It jsut assumes it's
44.1K and within tolerance. How then can my device, which is really
running at 44099Hz, but doesn't know it, tell the other device running
at 44101Hz to resample? Seems hard to do, especially when we start
talking about differences that are this small . Do we really want to
resample every frame of audio data when the two only get out of sync
by ine frame in 10 or 20 seconds? (44100.1 vs 44099.9) It's really a
mess when you start to think about two devices very close in frequency
but drifting around so that for one minute one card runs fast and then
for the next minute the other card runs fast.

More intereting (to me anyway) would be somehow extending the concept
RME builds into their hardware. In these cards the card can be the
master device or the card can sync to one of it's inputs. With this
feature a set of RME cards can all be in sync. (You know this, which I
know.) It would be interesting to extend the idea to some signal being
sent over Ethernet so that the slave card could sync up. This, of
course, requires hardware changes so it's not something that any of us
could do today, but going back to our Open Source Hardware project
ideas, it's a feature that would be cool to add to that. (I'm not
working on it today BTW...)

- Mark
Received on Mon Jan 17 00:15:07 2005

This archive was generated by hypermail 2.1.8 : Mon Jan 17 2005 - 00:15:08 EET