On Sunday 16 January 2005 02:22 pm, Mark Knecht wrote: > On Sun, 16 Jan 2005 12:19:01 -0500, Lee Revell <rlrevell@xxxxxxxxxxx> 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
