On Sunday 16 January 2005 02:22 pm, Mark Knecht wrote:
> 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-204a
> >672f11cf/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
-perk- time to catch up methinks
> 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 Tue Jan 18 00:15:04 2005
This archive was generated by hypermail 2.1.8 : Tue Jan 18 2005 - 00:15:05 EET