The No.1 Website for Pro Audio
 All  This Thread  Reviews  Gear Database  Gear for sale     Latest  Trending
Audio Interface - Low Latency Performance Data Base
Old 27th May 2019
  #3211
Lives for gear
 

Vin,

First, great work, of course!

But I need to know how you tested the Lynx TB system.
I have been using their AES16e PCIe card for many years, and am hoping to improve things slightly. (An oc'ed 9920x should help)

Your tests showed it slightly SLOWER than the Lynx PCIe system, yet Paul @ Lynx assures me that TB, properly implemented, is the fastest way to do audio i-o, and that I will definitely see a small improvement if I get a TB-equipped Aurora (n).

So the issue becomes "properly implemented" Thunderbolt, which opens up a medium sized can of worms. Did your mobo have native TB, with a good controller bypassing the cpu, or did it use a TB PCIe card? (I'm guessing the latter, as Windows mobos wit native TB have only hit the market n the last 6 months or less.)

Evidently there's a huge difference, although the specifics of this are making my head explode.
- And if anyone can explain those specifics & details I'd be very grateful.
Old 27th May 2019
  #3212
Lives for gear
Quote:
Originally Posted by speerchucker View Post
Vin,
I have been using their AES16e PCIe card for many years, and am hoping to improve things slightly. (An oc'ed 9920x should help)

Your tests showed it slightly SLOWER than the Lynx PCIe system, yet Paul @ Lynx assures me that TB, properly implemented, is the fastest way to do audio i-o, and that I will definitely see a small improvement if I get a TB-equipped Aurora (n).
Just by simple thought, that TB basically "tunnels" PCIe lanes via external interface, so I don't see any potential to be "faster" than internally connected card.
And I would probably add, that in context of audio interfaces, it's equivalent and doesn't really matter, whether you have PCIe or PCIe over TB.

So I don't think, you'll gain any improvement in that area.
Maybe Paul compared TB to other variants for direct connection of their new Aurora.. (eg. USB, Dante..), in that sense, TB is of course fastest way how to interface it.

Quote:
Evidently there's a huge difference, although the specifics of this are making my head explode.
- And if anyone can explain those specifics & details I'd be very grateful.
Where did you see huge difference? Both AES16e and their TB card performs pretty much the same to me. Maybe they implemented larger additional buffer for 32 samples ASIO buffer in their later driver (which can be beneficial for stability at such short working buffer lengths, RME made same thing for their drivers and IMO it's definitely better to trade absolute latency for more robust streaming), but that's about it.

To me, RTL differences between top scoring interfaces in Vin's benchmark are really small, IMO practically negligible to select one or another just because that.. eg. it doesn't really matter, whether it reaches 2.1 or 2.8. If you own such interface, it's pretty much at category of best performers, you can get. And you can focus on other concerns (I/O and expandability, stability of drivers, compatibility, control software).

Btw. whenever someone claimed, some new land speed record has been set with their forthcoming or new interface (that of course catches some attention), then as far as I can remember, there was always some devil hidden inside. Either it was far of real world result, because it was simply fabricated with some best case calculation, or it was without any safety buffer (which they also had to add finally, as nobody could work with that), possibly tradeoff was in missing features to gain some super small improvement in RTL figure (eg. shave couple of samples with no hardware mixing). So it was finally always somewhere around all good interfaces, we already have.
I personally don't see any chance to really cut that down, best RTL results are pretty much same like it was 10y ago. Of course, you have much more powerful CPUs, so you can afford shorter buffer or higher rate, but all of that you can also do, when you put an old card to brand new computer.
In absolute figures and with mandatory delays, I don't really expect anything groundbreaking or worthwhile for swap in any real-world situation.
IMO people who are working in DAW or play VIs, have to accept that. Others, who are super anal about any latency can monitor outside of computer.

My 2c

Michal
Old 28th May 2019
  #3213
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
Where did you see huge difference? Both AES16e and their TB card performs pretty much the same to me.
Read my post again, I've already explained it. Their TB card performed the same... with what hardware? If you used a TB PCIe adapter card, connected to a header, then that wasn't "true" TB, in the effecient way that Mac does it.

A very few new X299 mobos have onboard TB chips, and hopefully that's the answer, but details are still very hard to come by. Even three techs as Asus, and two at Gigabyte, knew nothing at all abut this. (They didn't even know their own comapnies had such mobos now available.)

Or do some Googling on TB implementation in Windows - but be prepared to get a bit overwhelmed since there is not a lot of clear information as of yet.
Old 28th May 2019
  #3214
Gear Addict
 
daskeladden's Avatar
 

I don't think a Thunderbolt port from a add on card is any slower or different than native Thunderbolt port. That is the first time I have heard that. Always nice to have a native port (like I have) but PCI + header should work the same. Would have been funny to try cause I also have a Thunderbolt header on my motherboard and hook that up with ThunderboltEX 3, and see if the results are any different than my native port. My bios only allow one active Thunderbolt port so I have to switch between them.
Old 28th May 2019
  #3215
Lives for gear
Quote:
Originally Posted by speerchucker View Post
Read my post again, I've already explained it. Their TB card performed the same... with what hardware? If you used a TB PCIe adapter card, connected to a header, then that wasn't "true" TB, in the effecient way that Mac does it.

A very few new X299 mobos have onboard TB chips, and hopefully that's the answer, but details are still very hard to come by. Even three techs as Asus, and two at Gigabyte, knew nothing at all abut this. (They didn't even know their own comapnies had such mobos now available.)
There is not much difference between boards with built-in TB or add-in card, besides mechanical construction and connectors in path. In both cases it's the Intel TB chips (like Cactus, Alpine Ridge, Titan Ridge), which is connected via PCIe lanes to CPU. The same applies for Mac hardware design, parts are common to both, neither one has more "direct" pathways.
In any case, it's not really possible, that would somewhat slow down audio interface RTL figures.

Quote:
Or do some Googling on TB implementation in Windows - but be prepared to get a bit overwhelmed since there is not a lot of clear information as of yet.
I can quite well imagine all the issues with discovery, reliability of setup, necessary steps and workarounds (different drivers, BIOSes, firmwares, builds of Windows.. etc.). But it would require bit stretch of imagination, that when TB device is already running, it would affect audio interface performance in a way, audio transfer would take measurably longer time.
So you'd get different RTLs (not speaking about other columns with count of plugin instances in test DAW, that's of course hard to replicate between different systems due to many factors involved) at different computers.
I have never experienced any differences in RTLs with the same interface with common settings and driver among different Windows computers, unless there was some mistake (mine ) in measurement.. regardless of bus (PCIe, USB, FW, TB).

With regards to performance at Mac vs. PC, it's hard to do, because there can be differences, but not really because of more effective TB, but because of inherent differences between operating systems (scheduling), its audio subsystems (ASIO vs CoreAudio). So driver can be designed bit differently and for example with different internal buffer sizes with intention to perform best at every platform. So results are rarely directly comparable.

I see, you're looking for some reasoning to what Paul mentioned to you. However I'm afraid, there can be lot of wishful thinking involved. To me Vin's results pretty much says, what I wrote about PCIe vs TB (eg. it's basically the same)
And I believe, he will respond to your post with further details.

Michal
Old 28th May 2019
  #3216
Here for the gear
 

Quote:
Originally Posted by TAFKAT View Post
Hey All,

Just tidying up of the back end, these updated charts should have been posted in January , but blink and we are now almost in June.

LLP Database Update: May 2019 :

Not a lot of updates the last year, but here is the summary of the additions.

Antelope DISCRETE 8 : Results speak for themselves, I/O and RTL at respective latencies is on par to RME's TB offering , efficiency is again pretty much identical. Thats no small feat and I commend the Antelope Team for delivering on the promise, very impressive.

Unit has buffer settings down to 8 samples, but I focused on latency settings of 032 and above to maintain consistency with the database, and also those respective and preferred working latencies that are more viable and have workable efficiency.

A race to the bottom re latency is good to a point, but if its at the expense of viability and efficiency, then its losing focus of the target goal. Driver needs a few dots connected regards WDM capability under TB, which has yet to be finalized as of date of writing this summary

I have posted the USB2 results as well, which is the Thesycon V4 driver under the skin, near identical performance to other offerings using the same base driver ( i.e Audient ) , same quirk with identical listed playback latency for 032/064 with slightly differing results ? , most like a kernel/safety buffer variance. Nothing much to report , same ole same ole. The variance between the TB and USB performance is quite significant , which was not unexpected.

Lynx Aurora LT-TB : The Lynx Unit performed pretty much as I expected once I resolved the initial gremlins. Very good I/O and RTL, with good efficiency and stability at the respective buffer settings, that we have come to expect from Lynx over the years. Not overly surprising to be honest with their experience of the PCIe products that the technology is derived.


Last 12 Months in Review : Things seem to be slowing down regards new units that are focusing on better LLP , most Thunderbolt devices have delivered on the premise of equaling PCIe , USB2/3 performance is still dominated largely by RME , while most others are dependent on Thesycon shuffling the deck chairs. Ethernet protocols like Dante and AVB are proving themselves viable solutions in live and non critical LLP environments, with a new comer promising to shake that area up, but verdict is still out.

I do have to mention the biggest non show being the insanely overhyped and continually absent Slate unit , which was supposed to have rewritten the book on LLP with its so called proprietary chip ( 20 year old ESI chip ) and game changing cross platform performance. Almost 2 1/2 years after the ShamWow product launch, we are yet to see a final Windows drivers and no one can manage to spend 5 minutes to test and upload a complete RTL log even on the final OSX driver.

I'll let you all form your own conclusions, but I believe the days of vapourware and marketing on hyperbole has long passed.

Thats it for now, I'll be back when I have some fresh interface results to share.

And for those wondering, the new DAWbench website is still in the works, and the DAWbench Radio Show podcast is still on and actually not too far away.

Thanks! Lots of interesting results here.
Particularly that the the Audient ID4 seems to perform a whole lot better than the ID22.
Does anyone have any idea why there's such a big difference? Aren't the driver's the same?

I've actually been looking to buy the ID44 but these results have worried me.
I use a fair amount of softsynths and 7ms at 32, or 12ms at 128, just doesn't seem up to standard.
Is there anyone with experience with the ID44 who can vouch for how well (or poorly) it holds up?
Old 28th May 2019
  #3217
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by speerchucker View Post
Vin,

Your tests showed it slightly SLOWER than the Lynx PCIe system, yet Paul @ Lynx assures me that TB, properly implemented, is the fastest way to do audio i-o, and that I will definitely see a small improvement if I get a TB-equipped Aurora (n).
There is a consistent 0.09ms variance in respective RTL's at each buffer setting between the AES16e/Aurora compared to the Aurora with the LT-TB configuration. That is as close to identical as realistically possible.

I mean really, that is barely quantifiable and by no means anything to be concerned about IMO.

I can't comment on Pauls assertions as I have no idea how he would even qualify or quantified that statement. The measured RTL is via the driver, AD/DA via the respective FPGA's on the cards, the TB protocol isn't really even a factor in the RTL results. Maybe the new Auroras have lower AD/DA latency, but what are we realistically talking about here , for reference and perspective, the old Auroras I used were 12-14 samples each way.

Quote:
So the issue becomes "properly implemented" Thunderbolt, which opens up a medium sized can of worms. Did your mobo have native TB, with a good controller bypassing the cpu, or did it use a TB PCIe card? (I'm guessing the latter, as Windows mobos wit native TB have only hit the market n the last 6 months or less.)
What exactly is "properly implemented" supposed to mean in the context of audio interfaces ? I have no idea what Paul is referring to ?

Thunderbolt implemented at the board level over PCIe cards may or may not have the addition of the Displayport interconnect , depending on how the respective manufacturers have chosen to roll it out. But that has no relevance to audio interfaces that are only requiring the PCIe x4 portion of the TB implementation.

There is no such thing as bypassing the CPU, as the PCIe lanes dedicated to TB are directly controlled by the CPU itself and either connected via respective PCIe slots or at the board level via quickpath.

The header itself doesn't come into play past security/licensing , from my understanding , there is no actual data throughput.

FWIW - My reference/dev system has a PCIe TB2 card , which is very rare and pretty much a unicorn. This allows me to test the units TB2 natively sans a Thunderbolt 3 to Thunderbolt 2 adapter , which may or may not also impact performance slightly. I have eliminated that factor all together.

So in summary , if you already have an AES16e/Aurora configuration, do a quick RTL test at your end and cross reference against mine ( I did the AES16e numbers a few years back now with an earlier driver ) , ask Paul from Lynx to do the same RTL testing at his end with the new Aurora(n) and compare the numbers.

As I mentioned earlier, the only possible variance can be the AD/DA on the new units.

Old 28th May 2019
  #3218
Quote:
Originally Posted by speerchucker View Post
If you used a TB PCIe adapter card, connected to a header, then that wasn't "true" TB, in the effecient way that Mac does it.
Thunderbolt is Thunderbolt. The way it is implemented is irrelevant for its performance or latency. It is only relevant for compatibility, which rather seems to be a specification tolerance issue between the various hardware/firmware/software/driver developers involved (as we also know from DisplayPort, AAF, OMF, Sony 9 Pin, etc.).
Old 28th May 2019
  #3219
Lives for gear
 

Quote:
Originally Posted by msmucr View Post
There is not much difference between boards with built-in TB or add-in card, besides mechanical construction and connectors in path. In both cases it's the Intel TB chips (like Cactus, Alpine Ridge, Titan Ridge), which is connected via PCIe lanes to CPU.
Quote:
Originally Posted by DAW PLUS View Post
Thunderbolt is Thunderbolt. The way it is implemented is irrelevant for its performance or latency. It is only relevant for compatibility, which rather seems to be a specification tolerance issue between the various hardware/firmware/software/driver developers involved (as we also know from DisplayPort, AAF, OMF, Sony 9 Pin, etc.).
Aye, both correct for performance, but the sticking point with onboard for me so far is that the controller is routed through another third party USB 3.1 solution and as far as compatibility goes, this is often where it goes wrong as Leon outlines in his response.

My hope was that when they finally truly make it native to the chipset, it'll be standardized by being run through the native Intel controller. By that point, I would expect compatibility problems to clear up, at least on Intel-based hardware where Apple is using the same base hardware.

Given that they keep bumping this back, however, and there is a real chance at this point that Mac's might drop Intel support before that even happens... as well as the AMD question. Well, who the hell knows at this point.
Old 28th May 2019
  #3220
Lives for gear
 

Quote:
Originally Posted by LilQuestionAsker View Post
Thanks! Lots of interesting results here.
Particularly that the the Audient ID4 seems to perform a whole lot better than the ID22.
Does anyone have any idea why there's such a big difference? Aren't the driver's the same?
It was my understanding that ID4 was cut down for the education market, with different converters and controller. I would have expected marginally reduced performance if anything, so that's a bit of a turn-up if so.

The rest of the ID range from 14 up is more unified I believe.
Old 28th May 2019
  #3221
I really would like to add to this. I do wish Tafkat could get his hands on any apogee USB interface (So if you can send him one - it looks like he lives in Australia). I think that they have delivered some fantastic products.
The more modern Apogee One, Duet, and Quartet models are delivering very good results. On par with the RME Babyface Pro.
So to everyone who only needs a low latency interface with one input I highly recommend the ONE, and for two inputs the Duet and four inputs the Quartet. Although for the price of a Quartet I would rather pickup a Used RME USB interface.
From my testings Apogee USB interfaces are right up there with RME. So Kudos to them for delivering! And I love their software. It is a clean elegant interface and responds very quickly. The interface just works, no messing with settings etc. The only thing I think they could do to make the software better is allow us to save settings and I would like to see them add a turn on/off phantom power button option on the main interface. Which they could easily implement and I have already emailed them about it.
So.... after all these testings the only USB interfaces that I would purchase would be RME and Apogee. Now if only Apogee would get it together and allow us to use the their thunderbolt interfaces on Windows; that would be a warm welcome
Old 28th May 2019
  #3222
Lives for gear
 
stella645's Avatar
 

Quote:
Originally Posted by LilQuestionAsker View Post
Particularly that the the Audient ID4 seems to perform a whole lot better than the ID22.
Does anyone have any idea why there's such a big difference? Aren't the driver's the same?

Quote:
Originally Posted by Pete Kaine View Post
It was my understanding that ID4 was cut down for the education market, with different converters and controller. I would have expected marginally reduced performance if anything, so that's a bit of a turn-up if so.
This is because iD4 omits the DSP mixer which adds a claimed 1.43ms to driver latency.
Old 28th May 2019
  #3223
Gear Guru
 
monkeyxx's Avatar
Quote:
Originally Posted by Dallon426 View Post
I really would like to add to this. I do wish Tafkat could get his hands on any apogee USB interface (So if you can send him one - it looks like he lives in Australia). I think that they have delivered some fantastic products.
The more modern Apogee One, Duet, and Quartet models are delivering very good results. On par with the RME Babyface Pro.
So to everyone who only needs a low latency interface with one input I highly recommend the ONE, and for two inputs the Duet and four inputs the Quartet. Although for the price of a Quartet I would rather pickup a Used RME USB interface.
From my testings Apogee USB interfaces are right up there with RME. So Kudos to them for delivering! And I love their software. It is a clean elegant interface and responds very quickly. The interface just works, no messing with settings etc. The only thing I think they could do to make the software better is allow us to save settings and I would like to see them add a turn on/off phantom power button option on the main interface. Which they could easily implement and I have already emailed them about it.
So.... after all these testings the only USB interfaces that I would purchase would be RME and Apogee. Now if only Apogee would get it together and allow us to use the their thunderbolt interfaces on Windows; that would be a warm welcome
How does the Apogee Duet hold up in 2019? I believe the design dates to 2012.

Compared to something like the UA Arrow

I can get both for $300-ish dollars. Apogee has the big benefit of being USB. Arrow has the benefit of no breakout cables and bus power.
Old 28th May 2019
  #3224
Lives for gear
 

Quote:
Originally Posted by DAW PLUS View Post
Thunderbolt is Thunderbolt. The way it is implemented is irrelevant for its performance or latency. It is only relevant for compatibility, which rather seems to be a specification tolerance issue between the various hardware/firmware/software/driver developers involved (as we also know from DisplayPort, AAF, OMF, Sony 9 Pin, etc.).
Based on what I have read, this is totally false. (though it might have been true a year ago.)

Some TB imlementations completely bypass the cpu. Others (add on cards, I assume) do not. Anything that minimizes cpu load is going to have a benefit for low-latency (small buffer) performance.

Also, controller chips change all the time.

But again, specifics are murky at best ....
Old 28th May 2019
  #3225
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by Pete Kaine View Post
Aye, both correct for performance, but the sticking point with onboard for me so far is that the controller is routed through another third party USB 3.1 solution and as far as compatibility goes, this is often where it goes wrong as Leon outlines in his response.
Say what , running the onboard through a 3rd party USB3.1 controller ?

If that is the case, that is as useless as tits on a bull .

That was certainly not the case with boards I used with onboard TB3 in my last gen deployments. If that is the case now, I am happy to stick to PCIe cards, at least we know where the bodies are buried.

Old 28th May 2019
  #3226
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by speerchucker View Post
Some TB imlementations completely bypass the cpu. Others (add on cards, I assume) do not. Anything that minimizes cpu load is going to have a benefit for low-latency (small buffer) performance.
.
I have already explained that is completely false , the required PCIe lanes are running on the CPU itself.

The variance between the 2 Lynx solutions I posted are in the small delivered performance variance in the benchmarks themselves, if there was a performance hit with the TB testing being done via a card, none of the TB interfaces would have performed anywhere near what they did.

If anything, after what Pete just noted, some onboard TB implementations are the problem, not the PCIe cards.

Old 28th May 2019
  #3227
Lives for gear
Quote:
Originally Posted by Pete Kaine View Post
Aye, both correct for performance, but the sticking point with onboard for me so far is that the controller is routed through another third party USB 3.1 solution and as far as compatibility goes, this is often where it goes wrong as Leon outlines in his response.
Yes, I commented that purely from performance standpoint with audio interfaces..
I know and experience various compatibility issues, but basically same problems can appear with AIC as with on-board solution.

Any TB 3 controller chip by requires at least two third party components, which aren't made by Intel.. USB-C muxer and power delivery chip.
Both can play its role in compatibility of whole setup.
For example I've experienced issues with one device which worked at ASUS board with AIC card, but no-avail at on-board TB3 at Dell notebook.
Culprit was power incompatible delivery chip (which has btw. also own firmware), although device was self-powered.
So it can be real mess with that.. it doesn't depend just on component selection (like PD chip by TI), but also on vendor of final product and whether he make available all FW updates, TB drivers etc. This was for instance case with some Asrock AIC card, for instance both GigaByte and ASUS cards (with the same TB chip) had already incorporated FW updates from Intel.

Quote:
My hope was that when they finally truly make it native to the chipset, it'll be standardized by being run through the native Intel controller. By that point, I would expect compatibility problems to clear up, at least on Intel-based hardware where Apple is using the same base hardware.
Yes, I'm also looking forward to it.. I hope for better interoperability and more widespread adoption. However even if that will be in chipset or CPU, still some 3rd party components might be required.

Michal
Old 28th May 2019
  #3228
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by Dallon426 View Post
The more modern Apogee One, Duet, and Quartet models are delivering very good results. On par with the RME Babyface Pro.
Dallon,

What am I missing here, the RTL results you posted are in line with the Thesycon results achieved by others using the same driver ?

They are not anywhere near an BF Pro.

No idea on the actual efficiency at respective latencies , but I can't see how they would be different to other Thesycon results


Quote:
Now if only Apogee would get it together and allow us to use the their thunderbolt interfaces on Windows; that would be a warm welcome
A few years back ( might be more than a few ), I had a direct exchange with one of the heads of Apogee at the time who made it very clear the over riding culture at Apogee was Apple focused, and there was no one within in the company that could care less about Windows.

If thats changed , cool, but I would need to see more to be convinced.

Old 28th May 2019
  #3229
Quote:
Originally Posted by monkeyxx View Post
How does the Apogee Duet hold up in 2019? I believe the design dates to 2012.

Compared to something like the UA Arrow

I can get both for $300-ish dollars. Apogee has the big benefit of being USB. Arrow has the benefit of no breakout cables and bus power.

I have had both and Personally I like both. Apogee is bus powered and also allows you to plug in a midi device to it's back. Which is a nice added touch. I don't like UAD platform. I really don't like that you have to download all their plugins in order to use the Interface. And the arrow only has one sharc chip so..... It's only use is to run one or two plugins. I was using it with the unison preamps and I thought it sounded great. However, I like that the apogee has no DSP and is straight forward.
Hard call really... They are both great little interfaces. Do not get the older apogee duet or duet 2, also I would stay away from the avid apogee Duet and quartet. Apogee has written better drivers than avid. The Avid isn't bad, but I did have some issues with it on Windows which is why I picked up the latest Apogee Duet. Which I think was released in 2015. My top three choices for 2inputs interfaces are
Apogee Duet
RME Babyface pro
UAD arrow.

Although the arrow does not have any significant improvement with rtl. They are all pretty much on par.

If UAD eliminated their silly plugin/audiointerface system I would probably opt for the Arrow.

I do not see UAD doing that anytime soon though.
They want to promote their plugins and generate more sales. I just wish it was optional.
Old 28th May 2019
  #3230
Gear Guru
 
monkeyxx's Avatar
Quote:
Originally Posted by Dallon426 View Post
I have had both and Personally I like both. Apogee is bus powered and also allows you to plug in a midi device to it's back. Which is a nice added touch. I don't like UAD platform. I really don't like that you have to download all their plugins in order to use the Interface. And the arrow only has one sharc chip so..... It's only use is to run one or two plugins. I was using it with the unison preamps and I thought it sounded great. However, I like that the apogee has no DSP and is straight forward.
Hard call really... They are both great little interfaces. Do not get the older apogee duet or duet 2, also I would stay away from the avid apogee Duet and quartet. Apogee has written better drivers than avid. The Avid isn't bad, but I did have some issues with it on Windows which is why I picked up the latest Apogee Duet. Which I think was released in 2015. My top three choices for 2inputs interfaces are
Apogee Duet
RME Babyface pro
UAD arrow.

Although the arrow does not have any significant improvement with rtl. They are all pretty much on par.

If UAD eliminated their silly plugin/audiointerface system I would probably opt for the Arrow.

I do not see UAD doing that anytime soon though.
They want to promote their plugins and generate more sales. I just wish it was optional.
Thanks the UAD "Ecosystem" as they call it is a bit of a ten thousand headed monster to me as well, I sold all of my Apollos and kept a Satellite.

Babyface Pro is also on my radar.

What I'm really shopping for right now is a Sound Devices MixPre 6 going to hopefully soon see how that one goes.
Old 28th May 2019
  #3231
Lives for gear
 

Quote:
Originally Posted by TAFKAT View Post
If anything, after what Pete just noted, some onboard TB implementations are the problem, not the PCIe cards.

That could be true.

It still begs the question: What is the best (lowest overhead) TB implementation, and do any prosumer mobos currently use it? I'm considering the new ASUS Prime X299-Deluxe II, which differs from the older version primarily in that it has an onboard TB chip. One would assume it's a very new chip, since this mobo just became available, but past that I can't get ANY information, not even from their online techs.

As for some implementations bypassing the cpu, again, this is what I have read, very specifically. (Google it for yourself.)
But it's impossible to know what's true & what's not, which is exactly why I'm raising this issue here.

- And not forgetting what Paul told me. (he's never been wrong before.) I just haven't had time to call him again & discuss this further.
Old 28th May 2019
  #3232
Lives for gear
Quote:
It still begs the question: What is the best (lowest overhead) TB implementation, and do any prosumer mobos currently use it?

...
As for some implementations bypassing the cpu, again, this is what I have read, very specifically. (Google it for yourself.)
But it's impossible to know what's true & what's not, which is exactly why I'm raising this issue here.
Maybe I don't understand now.. three other people replied you, the basic assumption is wrong and it doesn't play role in audio interface performance and you likely won't find any difference between TB implementations (whatever that means) with regards to that.

Are you asking for comments, experiences? Or you've already made your opinion on that based on some unknown source (which we should Google ) and trying to convince us, how that is important and that some TB setups has lower overhead?

I'm not disputing, what Paul had said to you.. but dancing around "properly implemented" without further context is meaningless IMO.


Quote:
Some TB imlementations completely bypass the cpu. Others (add on cards, I assume) do not. Anything that minimizes cpu load is going to have a benefit for low-latency (small buffer) performance.
There is likely still some misunderstanding.. or bad terminology.
Due to given topology no TB connection can't bypass processor (the integrated computer part with contains many internal units), because all PCIe lanes has ultimately go to CPU.

If we're talking about CPU involvement in actual data transfers (from and to device), then we could say, it's essentially bypassed, because hardware DMA (direct memory access) is used there.
Which means that after initial setup, transfers between RAM and memory in peripheral device is handled by a controller.
It was at PCI/PCIe and for TB there are DMA controllers in NHI part of every TB chip.
It has to be in all versions and implementations of TB, there are no variants without that.
It's one of basic differences compared to USB, which can also achieve high bandwidths with its latest versions, but there is still no hardware DMA.
Generally speaking, drivers for TB devices are almost identical to ones for PCIe devices, with addition of functionality for hotplugging and bandwidth arbitration.

That's the only thing, which I can associate to your "CPU bypass" and TB, but again DMA is part of standard, you can't do any implementation without that, becaue devices and drivers relies on that.

Quote:
Also, controller chips change all the time.
Subsequent Intel TB chips lineups were essentially introduced with new version of TB standard, that was the main reason for chip upgrades.
Additionally TB 3 has two lineups from 2016, Alpine and Titan Ridge.. both are pretty much equivalent, only the latter can accommodate newer version of DisplayPort (1.4).


To further add, I generally haven't experienced any performance differences with various audio interfaces.. when connected to direct PCIe slot, to PCIe slot via PCH, to PCIe slot via bridge and in external chassis. TB interface directly, TB interface daisy chained after another peripheral (so there are another TB chip between with own internal PCIe switch), TB interface through adapter (TB3 -> TB). Simlarly with legacy PCI interfaces bridged via additional chips to new boards without native slots.
All those paths with more hops, conversions and switches along means, there is added latency (indeed), so at first thought you can assume, it hampers performance. But those delays are rated in clock cycles of the very fast bus and it's meaningless in whole picture for our use case.
I'm not saying, all interfaces has to be necessarily compatible and working well under various described conditions, but when you make it work, you'll likely hardly find any performance difference.

YMMV..

Michal
Old 29th May 2019
  #3233
Gear Addict
 
daskeladden's Avatar
 

Quote:
Originally Posted by msmucr View Post
Subsequent Intel TB chips lineups were essentially introduced with new version of TB standard, that was the main reason for chip upgrades.
Additionally TB 3 has two lineups from 2016, Alpine and Titan Ridge.. both are pretty much equivalent, only the latter can accommodate newer version of DisplayPort (1.4).
Do you know if Asus Z170-Premium has Alpine or Titan Ridge? Just curious
Old 29th May 2019
  #3234
Lives for gear
Quote:
Originally Posted by daskeladden View Post
Do you know if Asus Z170-Premium has Alpine or Titan Ridge? Just curious
For Z170 that would be Alpine Ridge, Titan is the newest one from last year.

Michal
Old 29th May 2019
  #3235
Lives for gear
 

Quote:
Originally Posted by stella645 View Post
This is because iD4 omits the DSP mixer which adds a claimed 1.43ms to driver latency.
Ahhh, yes, that makes perfect sense. Thanks!

Quote:
Originally Posted by TAFKAT View Post
Say what , running the onboard through a 3rd party USB3.1 controller ?
Sorry, USB-C I guess...

3.1 is the standard including bandwidh, USB-C is the connector. You can run USB 2 standard with a USB-C port, but you wouldn't do.... so I just used 3.1 as shorthand, when I should have stated explicitly USB-C.

Admittedly, it confused the conversation. My bad.

Quote:
Originally Posted by TAFKAT View Post
That was certainly not the case with boards I used with onboard TB3 in my last gen deployments. If that is the case now, I am happy to stick to PCIe cards, at least we know where the bodies are buried.
Every board out there & add in card is routing through a USB-C controller port of some kind. Luck of the draw which one and if it'll work with timing critical devices.

Quote:
Originally Posted by speerchucker View Post
It still begs the question: What is the best (lowest overhead) TB implementation, and do any prosumer mobos currently use it? I'm considering the new ASUS Prime X299-Deluxe II, which differs from the older version primarily in that it has an onboard TB chip. One would assume it's a very new chip, since this mobo just became available, but past that I can't get ANY information, not even from their online techs.
Having dealt with most of those techs, I'm not overly surprised. Titanridge cards are shipping with any board from the last 6 weeks, but the change over was rather recent.

Not overly sure about it having less overhead through, must admit I haven't thought about a way to quantify that.

Quote:
Originally Posted by speerchucker View Post
As for some implementations bypassing the cpu, again, this is what I have read, very specifically. (Google it for yourself.)
But it's impossible to know what's true & what's not, which is exactly why I'm raising this issue here.
The standards are pretty strict with this, and that doesn't sound right. It's possible your talking about direct connections (like a GPU would use) to none direct connections (coming via the PCH) but it shouldn't otherwise have any impact.
Old 29th May 2019
  #3236
Gear Maniac
 

There is a gamer's forum www.egpu.io that provides some information and real-world benchmarks for TB and the different TB controller boards.

That forum is more focused on gaming laptops. The TB controller boards might be different (e.g. low power controllers), and the gamers are focused on GPUs (so their "issues" are limited bandwidth for video rather than "latency").

Regardless, the forum has some good databases and discussions around TB, TB accessories, and "crippled" TB products.
Old 29th May 2019
  #3237
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by vanallen View Post

That forum is more focused on gaming laptops. The TB controller boards might be different (e.g. low power controllers), and the gamers are focused on GPUs (so their "issues" are limited bandwidth for video rather than "latency").
A direct link to the discussion would be of value for those interested , but we are going way off tangent. TB implementations on some laptops has always been a minefield, and its directly related to how the Displayport interconnect is implemented, which is completely irrelevant to the discussion here, or my results I presented.

This is getting exhausting, I don't see the point of splitting hairs over a so called latency discrepancy of 0.09ms , and a minor change in overall performance on the benchmarks.

The unqualified claim by Paul from Lynx that a so called properly implemented TB will have a lower overhead and subsequent improved performance , has now placed a grey area over my TB testing, as if I have somehow not connected the dots.

How about using a TB3 to TB2 controller, has Paul taken that into account , there are after all encoders and decoders involved, which surely must be impacting overhead seeing the Aurora N is still using the same LT-TB TB2 controller cards as I used on the original Aurora.

So what exactly is this so called properly implemented TB he is claiming, would have to be TB2 for starters , wouldn't it ? !

The above is hypothetical as an example of the cyclic nature of the discussion, and unless I can be shown a direct correlation and performance variable, then I am placing this in the hyperbole tab !

I have had a good ongoing communication and relationship with Paul from Lynx, he can contact me directly.

Just to finish off, TB3 using a USB-C interconnect port doesn't necessarily mean its being pushed through a USB-C controller, 3rd party or otherwise, its simply the port connector they chose to use for wider acceptance, which has resulted in massive confusion I might add.

I can't see how/why the TB throughput from the PCIe cards are being pushed through a USB-C Controller instead of the dedicated TB controller on the card, makes absolutely no sense to me.

Wouldnt it be a higher likelihood that USB-C/3.1 is being pushed through the TB controller ? !

I digress.

Old 29th May 2019
  #3238
Lives for gear
Quote:
Originally Posted by vanallen View Post
There is a gamer's forum www.egpu.io that provides some information and real-world benchmarks for TB and the different TB controller boards.

That forum is more focused on gaming laptops. The TB controller boards might be different (e.g. low power controllers), and the gamers are focused on GPUs (so their "issues" are limited bandwidth for video rather than "latency").

Regardless, the forum has some good databases and discussions around TB, TB accessories, and "crippled" TB products.
That's good resource.. I read it quite a lot, when someone wanted to get TB chassis for iMac to host a GPU for Davinci Resolve to offload rendering from internal Radeon.
And you're true, that bandwidth can be real concern in some workloads, especially when using multiple demanding external peripherals (say eGPU, some external SSDs and for example USB 3.1 drives). In that sense problematic can be not just TB bus itself, but also internal topology in the computer. Like for mainstream CPUs with 16 lanes allocated to some internal GPU and everything else is gets connected to PCH.. so internal NVME drive(s), NIC, USB and TB controller.
Of course, when using HEDT CPUs (that unfortunately doesn't apply to notebooks nor majority of AICs), that can be much better.
However as always, one has to always judge particular situation in whole.. so while for example someone with eGPU and such iMac might be bottlenecked a bit by a bus (which is for example easy to find by CUDA-Z measuring memory-copy performance), still real-world impact for his workload might not be as dramatic as it can look from benchmarks and whole eGPU affair might be worthwhile, because despite all of that, it can still significantly improve performance compared to internal GPU.
But that's bit OT , and it's not really so relevant to audio interfaces.

Michal
Old 30th May 2019
  #3239
Lives for gear
 

Quote:
Originally Posted by TAFKAT View Post
The above is hypothetical as an example of the cyclic nature of the discussion, and unless I can be shown a direct correlation and performance variable, then I am placing this in the hyperbole tab !
So sorry you got your panties in a bunch.

I realize now you are the god of knowledge when it comes to low latency DAW performance, and I will keep this in mind for the future.

Please enjoy yourself.

Meanwhile, I'll try to find the information I need, to optimize my new build, elsewhere.

Again, my apologies! (What was I thinking? .....)
Old 30th May 2019
  #3240
Lives for gear
 
TAFKAT's Avatar
 

Quote:
Originally Posted by speerchucker View Post

Meanwhile, I'll try to find the information I need, to optimize my new build, elsewhere.
Ignoring the ad hominim attacks , you have been given all the information required by numerous knowledgeable participants on this thread , you haven't managed to clarify or qualify any of your claims, and refuse to accept and continue to dismiss anything that we have shared with you.

Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump