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-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