Although I agree with you, that DVS can be probably more efficient, it's still more just theoretical discussion in the context of Burl B16, same as comparison to Ravenna driver.

I'd be also very cautious with comparison of Ravenna software driver and some hardware interface. In my experience, those networked audio software endpoints are pretty much very sensitive to HW/SW configuration and utilization of the computer.
So although "best case" latency figure and track count will be very close, real world latency performance (with loaded project) and processing headroom might be quite different. So I'd very reserved to say something "match" just by RTL latency number.
Some endpoints might solve that by running completely at driver level and for example "hogging" one CPU cores just for those tasks.. like Ravenna Masscore or HONO VSC AVB endpoint, which both uses Windows RTX to overcome Windows scheduling performance.

It might be also driven by different Audinate decision about Dante.. compared to Merging/ALC NetworX, they have existing computer audio interfaces with HW endpoints with deterministic response and short buffers.. so there isn't any significant pressure to really optimize DVS as they have different (and arguably more bulletproof) HW solutions for that. So DVS was done with lower performance, but also more relaxed demands and reliable working at various computer configurations.
But, who knows, maybe there is some new DVS version on horizon.. There are more things, which can be possibly improved.. namely multi-client ASIO access at Windows for example.
However so far, we have to count only with what's available.

decisions For FOH live or broadcast use, that may be important point to have redundant paths and there are dedicated Dante product lines for that (like all Rednet models ending with ..R), but for small studio it's IMO unnecessary overkill.. and bit different thing that some room for future expansion.
Do you have redundant analog tie-lines to live room.. redundant AES or ADAT lines between your audio interface and converters? I've personally never seen that in smaller studios.

Anyway.. I see Red4Pre as quite groundbreaking product personally, especially for smaller studios.. I believe, something like that was missing at Dante ecosystem.
Hardware Dante endpoint with small deterministic latency, good quality I/Os, Digi Link and mainly that low latency mixer.. (which is IMO one of biggest issues with RedNet PCIe interface, unless you have outboard solution for that).

Michal

Yep, I was talking about info from posts in the interface database thread. So basically what you are saying is that Thunderbolt via an external expansion chasis is where it should be (a hair higher than an internal PCIe slot) which still leaves Thunderbolt Interface drivers or implementation of Thunderbolt in the interface itself as a culprit for their real world higher than expected latency numbers (as reported in that thread).

Any PCIe card interface is also going to take advantage of it's FPGA chip programing (if its got one) regardless of whether in an internal PCIe slot or external Thunderbolt chasis.

Yes.. that's what I've meant. I even wouldn't say, it's hair higher, because in those use cases, performance was the same.
TB adapter chip is directly connected via PCIe lanes. To some extent, it's similar to additional PCI to PCIe bridges, which are present at some motherboads without native legacy PCI slots. Although you have another chip in-line, it won't have any impact. There isn't another perceivable or measurable audio latency (technically there has to be something, but that delays are being measured in cycles of PCIe bus.. eg. GHz's).
Audio interface latency is set by driver and length of associated software and hardware buffers, so that remains the same and there isn't problem unless there is some under/overrun.
Another aspect is CPU utilization with streaming, but again IME, in both discussed cases, it's very low with audio, as hardware assisted DMA takes the place (compared to USB for example), so it's almost immeasurable at modern CPUs, even if you try to use kernel performance analyzers.
There are certainly some use cases, where you might hit the wall with particular TB versions, like setups with external multiple GPUs.. but we're talking about magnitudes different bandwidth here.

Yes, but that applies for any hardware peripheral (also for USB or Firewire), where you find advantageous to do custom quick processing/computing without use of dedicated chips (ASIC), with advantage of upgradeability. Otherwise, its being used for pretty long time.. basically you can imagine that as a breadboard for any logic chips.
So say, you can create one part, which handles audio streaming, another part taking care of synchronization and clock reconditioning and another part, where you can make custom DSP for mixing.. you need some specific DSP architecture, like multipliers or adders with arbitrary precision.. no problem.
Lately, it seems to me, FPGA is being used as kind of "magic" marketing buzzword, although you'll find it almost everywhere, when you look for Xilinx or Altera chips. Also when some vendor doesn't use them (for example he makes his products at the scale, where manufacturing of custom ASIC chips makes economic sense), it doesn't necessarily mean, it's performance has to be somewhat inferior. Execution of both for particular given task is much more important.

Michal

The latency figures and experiences I shared aren't theoretical or based on any particular manufacturer's marketing figures, they are based on day-to-day real world sessions.

As a long time user of both Dante and Ravenna, employing both systems on a daily basis in a variety of roles, it is fair to say that the results come from experience and not hearsay or what I've read somewhere online.


In discussions with colleagues, the latency figures mentioned previously with regard to the Ravenna CoreAudio driver, match their own results in real day-to-day sessions.

Hardware and software configurations varied, only the Ravenna CoreAudio driver version matched in all configurations, so no, your statement doesn't match my experience, nor that of the colleagues I have had discussions with.

That is not to say your experience isn't a valid data point.


Again, this isn't a "best case" scenario or some theoretical result based on someone else's marketing data.
Perhaps the Focusrite figures are "best case", but I haven't used their product, nor was I present during their testing to confirm their results to be accurate.

All I can do is use the data they officially provide publicly, and compare it to my own experience and results.


Not sure how this is relevant to the discussion, as I use neither Windows, nor do I employ Pyramix (nor do the colleagues I have had discussions with) where this may be relevant to the results mentioned.

As mentioned in my previous post, OS X.11 is installed on a Mac Pro using Reaper. This is what Focusrite mentions as their configuration in generating the latency results they have officially published. I simply compared my results to their official figures.


Not really a direct comparison, now is it?

Point-to-point connections pretty much guarantee the signal will reach the destination on time and in tact, and critically, these systems were originally designed to carry realtime audio and video signals. They do this quite well, and are trusted by a variety of organisations, in a variety of disciplines.

Ethernet, on the other hand, wasn't designed to carry real time audio and video. Ethernet also doesn't offer the same guarantees as point-to-point analogue or digital cabling with regard to timing, complete data arrival, et cetera. I've had this same discussion on another forum, pointing this out as people seem to have missed this very point as included in documentation provided by Audinate and ALC NetworX (which incidentally is a Lawo company not a Merging one), as well as by AIMS, AMWA, SMPTE, VSF, et cetera. This shouldn't be news but yet it seems to be.

Much R&D, by major broadcasters and research institutes and industry alliances, is still being spent today on workarounds in order to build a reliable and secure IP-based system for realtime audio and video that matches point-to-point connections such as AES, MADI, SDI, et cetera.

Hence, my suggestions, and it is the suggestion of these broadcasters and researchers that redundant networks are necessary in IP-based systems.

Sorry, there is misunderstanding.. to me it's theoretical discussion here, because Burl doesn't have (and likely won't have) Ravenna motherboard. I haven't questioned your experience with their driver.

By "best case" figures, I've generally meant just simple one figure round-trip latency measurements typically with one looped track.
While this is sufficient, when talking about hardware layer transport latencies or about general ballpark of some interface, when we really want to compare audio interfaces, efficiency and stability under increased load are also very important things. Basically how far you can push the system and DAW project, before you experience dropouts and xruns at given buffer length or RTL.

It's very hard to measure that by vendors or even multiple different users, because it's time consuming and you have to use exactly identical HW/SW environment and test project to do that.
However one might find quite significant differences among various interfaces and drivers (regardless its virtual or real interface). Although particular implementation is always very important, in general PCIe or TB interfaces will rule that aspect, because its hardware DMA for hardware buffers has almost no CPU overhead. Whereas other ways to access hardware (say via USB or L3 network audio generally) requires passing of payload (samples) through several OS software layers, which can take more time and CPU cycles. Also as it's passing through those asynchronous layers, when computer is being loaded, it's more difficult to keep required tight scheduling (when you have short buffers) as normal OSes.

There are certainly use cases, where this might not be really apparent.. so for example Horus rig, which I've seen, was used at big studio for orchestral recording and scoring.. they have lot of simultaneous I/Os, but very sparse and rather light DAW processing, so it's running stable with short buffers even during mixdowns.. however I can really imagine, when heavier bus effects or VIs, which would put more strain to RT performance, would be used, it might completely change the situation even with few tracks.

It was relevant to my previously mentioned point and our discussion about software endpoints, because this kind of dedication (hog at the driver level) of one CPU core just to processing or network audio handling helps to reduce influence of OS scheduling and other processes to time critical parts. So no matter what you do at DAW or system it gets scheduled and executed in timely fashion. I've mentioned it in the context of DVS and it's long buffers compared to hardware endpoints.

I'm afraid, you're mixing couple of different things.
First of all redundancy for networked audio/video protocols doesn't have anything with the fact, it's asynchronous nor it's build on top of IP based networks or some guaranteed delivery.. This has to be already handled in underlying protocols itself (generally in comparison to common point to point audio protocols, you have checksums there) even without any path redundancy, which won't help you with that. It's already working well, R&D was already done.
Redundancy there has only one purpose - availability in case of transport failure at primary path. Nothing more, nothing less.
Essentially it will help you with broken cable or failed network switch.. depending on topology (you can connect both ports to software partitioned switch with VLANs - in that case, it will cover cable failure.. or it can be connected to completely separate redundant network for more robust setups).
Audio payload and synchronization is always going through both paths up to the last redundant device, where both streams gets buffered and synchronized.. thanks to that, failover takes place immediately without any disruption or clicks.

So a need for redundancy at bigger or critical setups (broadcast, installation, live) isn't related to some technical differences between older protocols (which were also commonly done redundant way.. for instance in case of MADI or some proprietary optical SDI muxes), but mainly due to high impact of such failure when you have lot of channels multiplexed in one path.
Say you might have complex network topology and lot of audio channels going at TV station or some stadium, backbone network between two routing switchers.. etc. One failed network switch or broken cable between buildings and rooms can be total showstopper. When you previously had bunch of individual cables, transmitters, receivers with some spare lines, then it disrupted it, but after relatively short downtime, you could "survive" that. So there wasn't so high pressure for redundancy, unless particular project really required that and there was appropriate budget.

However back to my original point.. this isn't really anything, which small/medium studios should be concerned about.
From its perspective, it's really just interconnection between various boxes at one or two rooms, which replaces previous ptp protocols with couple of advantages. As they aren't broadcasters.. there it really doesn't make much sense to do all the cabling twice, purchase another switch and get more expensive Dante gear aimed for different segment just to have seamless failover, when they have multitude of other things in the studio, whose failure would require to stop their work or session.

Michal

Thank you for the clarification Michal, we seem to mostly agree on all aspects, perhaps approaching this from different angles.

I'm considering the MOTU 112D thunderbolt. This way I can keep my AES converters and add some Burl via B16 MADI.

The 112D itself creates 0.29ms total of latency, so even when converter latency and host software latency has been added the Round Trip Latency will be about as good as any. With my MOTU 1248, Logic reports RTL of 2.0ms @ 48Khz / 32 sample buffer, 6.0ms @ 48khz / 128 buffer. I would imagine 112D will be about the same.

RME MADI interface would definitely be my preferred route if I were ditching my current convertors.

I have a few questions about this...

I have a apogee symphony 2x6
I’m interested in the usb version

How would I route this? I’m interested in the d/a

So the usb version is discontinued?!?! Anyone have any inside info ??

and why is USB3 or thunderbolt so hard to implement ?

anyone know what's up with the USB card?