Paul Kellet wrote: > Paul Davis wrote: > > the question i have goes like this. > > > > you've got 1 bit at 44.1->96kHz, providing total bandwidth of > > 43-93kB/sec. with that bandwidth, you've got to: > > > > 1) encode temporal position > > 2) transmit transport state changes > > > <snip> > > so, i'm confused about exactly *what* they have done and *how* they > > have done it. > > I'm assuming it works like their (and emagic's) recent MIDI interfaces > - it sends everything ahead of time and leaves it up to the receiving > device to actually "play" the events at the correct time. The giveaway > will be if system link only works for recorded tracks, that can be sent > in advance by at least all the latency they are going to experience, > and not for live MIDI or audio input.
I don't know how Steinberg's and Emagic's MIDI interfaces work. :( I was assuming that the 24th bit is used like a serial interface, and the time code is gathered up bit by bit at the other end, so it takes many samples of audio data to extract the time code and have the information needed to match it up with other audio data streams. MIDI clock and SMPTE (I think) both work this way. MIDI timecode too, I think, although MIDI clock is the one I've read about more. Ok, so try this: suppose the clock is encoded as a 32-bit integer in the 24th bit. At a 44.1 KHz sampling rate, samples happen with a period of ~22.7 microseconds. 32 of those would take ~726 usec, which is less than a millisecond of latency. There are no start/stop bits necessary, because each click of the clock is the last plus one, and the other end can figure out from about 2 clock pulses where each starts. That is, 101010101010101 101010101010110 101010101010111 strung together would be 101010101010101101010101010110101010101010111 and the system on the other end can simply try out the signal shifted against itself by 32 and compared, to tell where the least-significant bit is. Does this make sense? I humbly apologize: I haven't had time to think it all through! The system wouldn't have to work only with recorded tracks. A live track (being recorded) could send data along with the timecode; just long enough to get the other end sync'd up, before the other end turned on its own audio stream. This would just be a little latency on the other end. I think maybe Steinberg is accepting a significant amount of latency to get System Link to work at all! Consider how much latency must be involved in an arbitrary number of daisy-chained, and possibly "legacy", computers! (Steinberg says System Link will work with any number of computers.) And hey, if a clock signal can be done in just one bit, I wonder how much MIDI data can be put in just one more bit... My impression of System Link is that it's kinda a hokey hack, but I have to admit, I wouldn't be upset if I found out I were getting only 22 out of 24 bits! That part of the audio signal is usually way below the noise floor, or at least totally inaudible anyway. > What I'm interested to see is if they've arranged the data carried in > the lowest bit to have a white spectrum, so you could still use that > channel for carrying 15- or 23-bit audio. That would be clever, using it to also dither the audio signal. But, dithering only works right when it is done at the last step (final mixdown). So it would seem that they are simply giving up a bit of resolution, in the same way "watermarking" or encoding secret messages works with digital images or audio. In the case of 24-bit audio, it would be interesting to see who claims they can hear the difference between plain 24-bit and the same content after being sent through System Link. ;-) As for reducing the audio content to just 15 bits, I think it would be extreme if System Link were ever to use up a full 8 or 9 bits of audio, but it might be possible. I'm *sure* many people will say they can easily tell the difference between regular 24-bit audio and the same with 9 bits of digital data "noise" added to it! Er, what I mean is, I would think System Link requires a 24-bit digital connection to start with, and wouldn't even try to function with a 16-bit connection. Or at least, I would hope not. Jay Ts
