lightbridge vs Symphony System

[wave rider]

I recently did the move from Pro Tools M-Powered to the Logic and love it. Some may argue but to me it just sounds better and once I got used to the work flow I love it.

Anyways, I have a profire lightbridge that I use with an Apogee AD-16x and was wondering what the advantage would be if I were to get the Symphony Cards installed and a DA-16x. Besides having more DA channels what would the advantage be? Less latency? Anything else? I don't have much trouble with the latency with the profire as of now.

[dkatz42]

Originally Posted by wave rider

I recently did the move from Pro Tools M-Powered to the Logic and love it. Some may argue but to me it just sounds better and once I got used to the work flow I love it.

Anyways, I have a profire lightbridge that I use with an Apogee AD-16x and was wondering what the advantage would be if I were to get the Symphony Cards installed and a DA-16x. Besides having more DA channels what would the advantage be? Less latency? Anything else? I don't have much trouble with the latency with the profire as of now.

A big deal for me has been the "advanced routing" mode of the 16x's when you use an X-card. Since the computer I/O is through the Symphony bus, the 16X digital and analog sides are separated; you not only have 16 in/out analog, but an additional 16 in/out digital. I use Maestro as a digital patchbay for all those AES ins and outs, and can do some crazy routing stuff (I run iTunes on a Mac Mini and feed the output via FW and a handy ULN-2 into the Digital 2 in on my Avocet for doing reference checks, and mult a digital out the other way for Spectrafoo and a software tuner, for example.) The digital I/O on my HEDD is hooked up this way as well, so I can do an external digital loop for the processing. Etc.

The low latency is nothing to sneer at either. I do all of my tracking headphone mixes out of Logic (with more crazy routing) and the latency is inaudible.

[figgebass]

Hi guys.
These last few weeks I have been trying The SSL Extreme Madi card with an SSL Alpha logic interface, Protools hd with a 192, Rme hdspe aio and an Apogee Symphony card with a Rosetta 800.
The Rosetta is the winner for sound but for latency it just don't cut it....=/
It's by some margin the slowest of them all....When I select the symphony card in the core audio driver menu in logic 9 it says "round trip latency 5.7 ms" at 32 samples buffer.
When I run the SSL Madi for example it says 2.0 ms. If the madi card had lightpipe in/out or aes in/out I'd buy that and the rosetta BUT it doesn't so now I am a bit confused...Do you set it up differently or do you just live with that kind of latency?
I have an 8 core nehalem mac pro so I think my compouter should be fast enough...

What do you think?

[dkatz42]

Must be a (mis)feature of the Rosetta. I think the quoted latency for my Symphony/16X combo is just a bit over 1 msec (at 96K).

[figgebass]

yeah, it's 1.6 at 96....
SSL Madi has a latency of 2ms at 44.1 and 0.9 at 96.
However...that's really not the whole picture since they get those numbers from sending pings or recorded AND buffered(Which means that the computer already has done its maths before we hear any sound, hence no latency coming from that process) data out and back in again.
What is more important is the time it takes to record something into logic that needs to be routed back out again. When I did a test like that the round-trip through logic was 5.3 ms with the SSL. God knows what it would be with the Symphony.... =/
I wonder what times the RME hdspe gets cos I tried that some weeks back and it was pretty fast but the d/a sucked monkeynails through the breakout cable...I was trying a cheap route back then...;-)

[dkatz42]

Originally Posted by figgebass

yeah, it's 1.6 at 96....
SSL Madi has a latency of 2ms at 44.1 and 0.9 at 96.
However...that's really not the whole picture since they get those numbers from sending pings or recorded AND buffered(Which means that the computer already has done its maths before we hear any sound, hence no latency coming from that process) data out and back in again.

This is a little misleading. The time to calculate a single sample must be significantly less than a sample time, or you could never actually operate in realtime. Thus there is no need to set aside any more time for this beyond the 32 samples you referred to.

Disk buffering has no impact at all on round-trip latency; it comes into play when you first press the Play button as a small pause (and if the software is smart, it is done *before* you press Play based on the position of the SPL).

What is more important is the time it takes to record something into logic that needs to be routed back out again. When I did a test like that the round-trip through logic was 5.3 ms with the SSL. God knows what it would be with the Symphony.... =/
I wonder what times the RME hdspe gets cos I tried that some weeks back and it was pretty fast but the d/a sucked monkeynails through the breakout cable...I was trying a cheap route back then...;-)

When I get back to my rig I'll have to pull out my scope and actually measure the analog-to-analog-through-the-whole-swamp path, but it is pretty short. The Symphony card itself has virtually no latency; the majority of it is in the A/D/A conversion process and whatever buffering is happening in the driver to provide a little elasticity. For what it's worth, the ping measurement in the D->A->D direction is less than a millisecond according to the I/O plug.

But you hit the nail on the head--the only latency path we really care about is the A->D->A path while doing software monitoring; the rest doesn't matter, assuming accurate delay compensation.

[figgebass]

I don't really get it...are you telling me that the rosetta is what's causing the latency since you say that the symphony card has "virtually no latency"?
I'm not so sure...
Here's the apogee page:
Apogee Electronics > Products > The Symphony System where it says that the symphony system has a latency of 1.6 ms at 96 khz.
Here's the page of the ssl madi extreme -alpha link that has 0.9 ms round trip latency at 96:
Solid State Logic | Music
To calculate what the symphony latency at 44.1 would be you'd have to add a little more than 2x1.6 resulting in what, 3.5 or so....if then the rosetta converts a bit slower than the Alpha link then I guess ....but at the same time I don't quite understand where the 5.7 ms comes from that my core audio driver states when I select symphony in the menu....

[figgebass]

one thing though......I have an 8 core mac...do I need to insert the card at any place special? Like the top slot or the bottom slot or whatever....It's full right now woth a Protools hd , the madi extreme and the symphony but I can change places if that may have anything to do with it...

[dkatz42]

Originally Posted by figgebass

I don't really get it...are you telling me that the rosetta is what's causing the latency since you say that the symphony card has "virtually no latency"?
I'm not so sure...
Here's the apogee page:
Apogee Electronics > Products > The Symphony System where it says that the symphony system has a latency of 1.6 ms at 96 khz.
Here's the page of the ssl madi extreme -alpha link that has 0.9 ms round trip latency at 96:
Solid State Logic | Music

My father years ago gave me a book called "how to lie with statistics."

There are apples and oranges here. The spec on the Symphony "system" includes the (presumably) best-case latency *including the A/D/A conversion*. They are unclear as to exactly which converters provide the 1.6 figure (thus my guess that the Rosetta perhaps had higher conversion latency than the 16x.)

The SSL is MADI-to-MADI, which does not include any A/D/A conversion. You have to add the converter latency at the other end of the lightpipe to the figure to get a realistic latency number.

My comment that the Symphony card has "virtually no latency" is because it does almost nothing--it's a digital pipe and I'd bet that the time to get samples across that card is measured in microseconds. The latency associated with the card comes almost entirely from the buffering necessary to give the system elasticity--the bigger the buffer, the more leisurely the rest of the system can be about delivering samples, at the cost of latency.

And of course the conversion latency has to be added to this.

To calculate what the symphony latency at 44.1 would be you'd have to add a little more than 2x1.6 resulting in what, 3.5 or so....if then the rosetta converts a bit slower than the Alpha link then I guess ....but at the same time I don't quite understand where the 5.7 ms comes from that my core audio driver states when I select symphony in the menu....

Keep in mind that the Core Audio figure is that which the driver reports to CA. In particular, the SSL driver cannot tell what the conversion latency is at the other end of the MADI link, since it doesn't know what kind of equipment is there. The Symphony driver knows what kind of box is connected to the bus, so it can take the converters into account.

I'm a thousand miles from my rig, so I can't compare your numbers with mine (with 16Xs). But it should be relatively easy to measure the latency with an oscilloscope. My hunch is that the SSL numbers aren't really accurate, because they can't be.

[dkatz42]

Originally Posted by figgebass

one thing though......I have an 8 core mac...do I need to insert the card at any place special? Like the top slot or the bottom slot or whatever....It's full right now woth a Protools hd , the madi extreme and the symphony but I can change places if that may have anything to do with it...

Doesn't matter; all the slots are the same, as far as the Symphony card is concerned. (Some slots can support higher bandwidth by providing multiple data lanes, but the Symphony card only has one data lane so it can't use more, but it doesn't have to--even a Symphony 64 running all channels at 192K will use roughly 10% of a single lane, if my back-of-the-napkin calculations are right.)

[figgebass]

Originally Posted by dkatz42

My father years ago gave me a book called "how to lie with statistics."

There are apples and oranges here. The spec on the Symphony "system" includes the (presumably) best-case latency *including the A/D/A conversion*. They are unclear as to exactly which converters provide the 1.6 figure (thus my guess that the Rosetta perhaps had higher conversion latency than the 16x.)

The SSL is MADI-to-MADI, which does not include any A/D/A conversion. You have to add the converter latency at the other end of the lightpipe to the figure to get a realistic latency number.

My comment that the Symphony card has "virtually no latency" is because it does almost nothing--it's a digital pipe and I'd bet that the time to get samples across that card is measured in microseconds. The latency associated with the card comes almost entirely from the buffering necessary to give the system elasticity--the bigger the buffer, the more leisurely the rest of the system can be about delivering samples, at the cost of latency.

And of course the conversion latency has to be added to this.



Keep in mind that the Core Audio figure is that which the driver reports to CA. In particular, the SSL driver cannot tell what the conversion latency is at the other end of the MADI link, since it doesn't know what kind of equipment is there. The Symphony driver knows what kind of box is connected to the bus, so it can take the converters into account.

I'm a thousand miles from my rig, so I can't compare your numbers with mine (with 16Xs). But it should be relatively easy to measure the latency with an oscilloscope. My hunch is that the SSL numbers aren't really accurate, because they can't be.

Ok...I tested the SSL-rig and my old Protools mix system by going analogue out and back in again.
The difference between the new and original files were just below 2.0ms on the ssl and just above 2 ms on the protools.
However when I was playing bass through both systems it was obvious that the ssl was slower (yeas, I am extremely sensitive towards latency or deviations from linearity of tempo etc , ok? ;-)) than the protools rig.

I then played the originalfile, on the ssl, out analogue 1 and back in analogue input 2, recorded on that track and routed it out analogue 2 into analogue in 3 and recorded that track at the same time. Now the difference between the original and track 2 was still 2 ms but between track 2 and 3 it was 5.3 ms....now how is that?...
On my protools rig it was 2.0x between original and track 2 and 2.0x between 2 and 3 and onwards...
My translation of that is that 3.4 ish ms were added by logic because when it was recording material that wasn't buffered (which is the case of the playback of track 1 but not the "play through" on track 2 while recording) it took some more time.
Hence 5.3 ms being the more accurate calculation of the actual latency of my fingers hitting the strings to the sound coming back out of the speakers....

So..anyway....yes the ssl's roundtrip latency was 2ms to , in and out of analogue, and back from the alpha link ....

Tomorrow I will perform the same test on the symphony rig. Since I can feel that the latency on it is worse than the , brand new I must add, Madi extreme-Alpha Link I would be surprised if the numbers showed me anything else...

[figgebass]

by the way....is ad/da latency anything to even consider nowadays?
Do we have any figures on how many samples it takes for a rosetta to A/D? Or a 16x ...

[dkatz42]

Originally Posted by figgebass

Ok...I tested the SSL-rig and my old Protools mix system by going analogue out and back in again.
The difference between the new and original files were just below 2.0ms on the ssl and just above 2 ms on the protools.
However when I was playing bass through both systems it was obvious that the ssl was slower (yeas, I am extremely sensitive towards latency or deviations from linearity of tempo etc , ok? ;-)) than the protools rig.

I then played the originalfile, on the ssl, out analogue 1 and back in analogue input 2, recorded on that track and routed it out analogue 2 into analogue in 3 and recorded that track at the same time. Now the difference between the original and track 2 was still 2 ms but between track 2 and 3 it was 5.3 ms....now how is that?...
On my protools rig it was 2.0x between original and track 2 and 2.0x between 2 and 3 and onwards...
My translation of that is that 3.4 ish ms were added by logic because when it was recording material that wasn't buffered (which is the case of the playback of track 1 but not the "play through" on track 2 while recording) it took some more time.
Hence 5.3 ms being the more accurate calculation of the actual latency of my fingers hitting the strings to the sound coming back out of the speakers....

So..anyway....yes the ssl's roundtrip latency was 2ms to , in and out of analogue, and back from the alpha link ....

Tomorrow I will perform the same test on the symphony rig. Since I can feel that the latency on it is worse than the , brand new I must add, Madi extreme-Alpha Link I would be surprised if the numbers showed me anything else...

While this is all interesting (and somewhat curious) it isn't a realistic test if what you're trying to determine is the latency in the headphones when monitoring (which is all that really matters, IMHO.) There's too many other variables cluttering the picture. One could test that look with an O-scope, or feed the original signal and the looped signal into two channels on a separate recording rig and see how those tracks relate to one another.

[dkatz42]

Originally Posted by figgebass

by the way....is ad/da latency anything to even consider nowadays?
Do we have any figures on how many samples it takes for a rosetta to A/D? Or a 16x ...

The converter latency becomes a larger and larger fraction of the total latency as the other components of latency are reduced. Whether those numbers are considerable or not depends on how sensitive to latency you are (or your application is.) I have a vague recollection of conversion delays being on the order of tens of sample times, but it depends on the chips in use as well as the design of the circuits in which they reside.

Certainly when latencies were measured in the tens of milliseconds, the ADA component was in the noise; now that we have fast enough machines and I/O subsystems to cut the buffering down, the conversion latency is a sizable fraction of the total.

[figgebass]

Originally Posted by dkatz42

While this is all interesting (and somewhat curious) it isn't a realistic test if what you're trying to determine is the latency in the headphones when monitoring (which is all that really matters, IMHO.) There's too many other variables cluttering the picture. One could test that look with an O-scope, or feed the original signal and the looped signal into two channels on a separate recording rig and see how those tracks relate to one another.

I am trying to get a more true picture of the amount of latency I have to deal with when sending an unknon piece of music into logic ,via an interface and a card , and back out again....and it's not below protools because then my search would be over....hence I had to go one step further by recording the output of a recording track...

[figgebass]

Originally Posted by dkatz42

The converter latency becomes a larger and larger fraction of the total latency as the other components of latency are reduced. Whether those numbers are considerable or not depends on how sensitive to latency you are (or your application is.) I have a vague recollection of conversion delays being on the order of tens of sample times, but it depends on the chips in use as well as the design of the circuits in which they reside.

Certainly when latencies were measured in the tens of milliseconds, the ADA component was in the noise; now that we have fast enough machines and I/O subsystems to cut the buffering down, the conversion latency is a sizable fraction of the total.

If ad/da really was a major part of the whole sum....wouldn't the numbers be somewhere to read about?Not even my old mackie d8b caused any latency that I could detect...

[dkatz42]

Originally Posted by figgebass

I am trying to get a more true picture of the amount of latency I have to deal with when sending an unknon piece of music into logic ,via an interface and a card , and back out again....and it's not below protools because then my search would be over....hence I had to go one step further by recording the output of a recording track...

My only point is that measuring the round-trip time out of the box and then back in may not yield the same results as measuring the round-trip time in through the box and back out, which is the path you seem to care about.

[dkatz42]

Originally Posted by figgebass

If ad/da really was a major part of the whole sum....wouldn't the numbers be somewhere to read about?Not even my old mackie d8b caused any latency that I could detect...

It just means that the overall latency is getting down to the point where we can't detect it easily, which is a good thing. A major part of a small number is still small.

The numbers for stock chipsets are available from the chip vendors. I don't see the gear manufacturers talking much about these numbers, but in some sense they don't matter other than academically, since it's the total latency that you experience.

[figgebass]

Originally Posted by dkatz42

My only point is that measuring the round-trip time out of the box and then back in may not yield the same results as measuring the round-trip time in through the box and back out, which is the path you seem to care about.

Well ofcourse it is....that's the way the sound travels when you play an instrument or sing through a mic...!
Anything else is just numbers...but the path that really defines how it feels to play or sing through a system is the one u mention...

[wave rider]

SO... what about sound quality? Any comments there? Is the Lightbridge in any way hindering my sound quality?

[Miraclesleeper]

Originally Posted by wave rider

SO... what about sound quality? Any comments there? Is the Lightbridge in any way hindering my sound quality?

I would like to know the answer to this aswell. I have been saving for new converters to upgrade from the Duet for sometime and have pretty much decided on the UA 2192 and a Presonus Lightpipe as it's rackmountable. I've emailed a few companies about this and they say that the firewire device doesn't affect the sound quality. I don't know why I keep asking the same question. Are the M-Audio and Presonus the only 2 options?