Focusrite REDNet

[jabbr]

Not true if you use direct computer-->device connection. See my previous post and posts by others explaining their setup.

 

No, need to frighten people.

But yes, this is a Pro-audio device capable of being used in complex audio networks. But it can be used in simple setup as well.

 

Many things can be used in complex networks but for our purposes here there is a need to work in simple networks as well so I stand by my comments. There are specific situations where the complexity is needed -- really not for the current generation of home audio products nor users. Moving back to point to pint connections is a poor step backwards which I don't encourage.

[Aleg]

Many things can be used in complex networks but for our purposes here there is a need to work in simple networks as well so I stand by my comments. There are specific situations where the complexity is needed -- really not for the current generation of home audio products nor users. Moving back to point to pint connections is a poor step backwards which I don't encourage.

 

If you use a Rednet D16, it has 2 RJ45 ports.

Connect one to your computer and one to your LAN. No difficult switch configurations required.

 

If you use a Rednet 3, it only has 1 RJ45 port.

Get a second NIC on your PC so your PC has two ethernet ports, and connect one to the Rednet 3 and the second one to the LAN. No need to use difficult switch configurations either.

 

So yes, if you want to get into the pro-level network setup, yes you will have to do pro-level network management as well. But it can be easily avoided by going another route.

And BTW, many cheap (semi-managed) SMB switches offer QoS settings already (not sure if they are using 4 queues though) and cost only little more than unmanaged switches.

[Aleg]

I've been reading this and related threads with curiosity but also some puzzlement. I've been somewhat familiar with RTP since the early days of IP telecom (which I did some work with back then), and with internet protocols and their Ethernet implementations pretty much since their start. I can't understand the benefits of AES67 over UPnP/DLNA for single-ended consumer applications. In both cases, packet payloads need to be decoded, buffered, and rendered as accurately clocked bit streams by some device for presentation to a DAC. The protocol delivering the packets to the rendering device just needs to take care that packets are not dropped or delayed beyond what the device's buffer can cope with. With those provisos, SQ will only depend on the timing and electrical properties of the connection from the device to the DAC. So, why do we need AES67 for (high-end) consumer use? It's of course possible that pro devices like those from RedNet are just better renderers (better clocks, better electrical properties) than consumer alternatives, but that would not have anything to do with the choice of Ethernet protocol.

 

I'm not familiar with the details of the DLNA/UPNP protocol, apart from bad experiences when using it and I kept far away from it eversince, but others with more knowledge about it condemn it to burn in hell for ever.

 

I can imagine that the content of what is transfered in the IP-packages requires a different kind of rendering at the receiver end. We already know from experience that more CPU activity at the renderer that is connected to the DAC, is bad for sound quality. So that could also be an explanation apart from the possibilities you already raised.

[Matty70]

Great to see that more and more of you guys are interested in AoIP and the Rednet products

 

I bought my D16 AES about 3 months ago, so perhaps the time has come to report my experiences.

 

Other than the majority, I really have the need for a multi channel solution.

I'm using AcourateConvolver as an Active XOver for 2x3 way + 3 subwoofers, what means, that I need to transfer 9 channels of output.

I'm using Roon as a player, HQPlayer for changing the sample rate to 96kHz an AcourateConvolver for convolving (XOver and room correction).

 

When I initially installed the Rednet D16 in my network I had many problems with that configuration.

To make it clear - transferring 2 channels of audio at any sample rate had never been an issue at all in my configuration.

 

But 9 channels of 96/24 had been a different thing. The latency in my system was sometimes exceeding the upper limit of 10ms resulting in dropouts. And there was no stability in the connection. Sometimes it worked, sometines not.

 

The first measure was to replace the onboard ethernet interface by a special Intel Ethernet-Server-Adapter. This improved the average latency, but the latency still was not stable.

The next change was to replace my US Robotics switch by an Netgear GS724T, which is one of the recommended ones on the Focusrite Webpage. I had the opportunity to get a used one very cheap so there was no risk of misinvestment for me.

I configured it like described on the Focusrite Webpage and this was the crucial improvement.

I now have an average latency to the RedNet device of about 2.5ms with no spikes anymore.

 

What I also experienced is, that the system responsiveness of the source computer can influence the dante latency too.

As a convolving computer can produce real heavy load, the next measure was to optimize the system throughput and responsiveness by experimenting with the software 'process lasso'.

I got some very interesting findings with that (AMD FX processors are not ideal for heavy floating point calculations), but this is a different thing.

 

Another problem I was facing was, that HQPlayer denied to work together with DVS. This seems to be solved with the new beta version 3.14. For the time being I helped myself by using a Raspberry Pi with HQPlayer NAA, feeding a physical input of the RedNet D16. but of cause this was not the intention.

 

I'm really happy that my configuration now works. I was able to banish all the computer stuff out of the linving room into a server rack in the cellar.

 

What I really love with Dante, is that I now can completely seperate my playback equipment from the measuring equipment. If I want to re-calibrate my system, I can connect the microphone on any computer, connect it to the dante network, and configure the routing with the dante controller. Especially Dante Via makes a holistic system out of your network and its devices.

 

How it sounds?

At least as good as before when I was using an AES soundcard (I tried different ones).

As it took me a while to get it running properly, an A/B test was not possible.

But I have less noise now, because my computer with its fans is far away from my listening place.

 

Best

Matthias

[Qhwoeprktiyns]

I am also running a system with multichannel (only 4 though). I just saw that xmos has a new xcore based multichannel card with AVB input (and i2s outputs, which I am using).

 

What are the advantages of Dante over AVB?

[jabbr]

If you use a Rednet D16, it has 2 RJ45 ports.

Connect one to your computer and one to your LAN. No difficult switch configurations required.

 

If you use a Rednet 3, it only has 1 RJ45 port.

Get a second NIC on your PC so your PC has two ethernet ports, and connect one to the Rednet 3 and the second one to the LAN. No need to use difficult switch configurations either.

 

So yes, if you want to get into the pro-level network setup, yes you will have to do pro-level network management as well. But it can be easily avoided by going another route.

And BTW, many cheap (semi-managed) SMB switches offer QoS settings already (not sure if they are using 4 queues though) and cost only little more than unmanaged switches.

 

Being "into" pro level networking, I like to balance complexity and benefit -- things should be as simple as possible.

 

Ok so multi-homed (2 network cards/ports) ouch! for no sonic benefit.

 

I do agree that cheap semi-managed switches are abundant. Again if someone is using multichannel and direct-Dante DACs then yes, the technology is awesome -- it's just for the average person here (CA) who wants to convert Ethernet (eg NAA) to USB or SPDIF , there's no need for QoS or multihomed. Maybe a "simple networking" setting could turn the clocks and broadcasting off ?? but I understand that's not in the target audience

[mourip]

Many things can be used in complex networks but for our purposes here there is a need to work in simple networks as well so I stand by my comments. There are specific situations where the complexity is needed -- really not for the current generation of home audio products nor users. Moving back to point to pint connections is a poor step backwards which I don't encourage.

 

Many of your previous points may be valid and reasonable theory. I agree that the REDnet devices are definitely overkill in terms of functionality and may be initially harder to set up for some. In terms of simplicity for the number of devices needed it is very simple. Ethernet cable>REDNet device> digital cable of choice> DAC. How many of us that have set up good sounding USB chains can say that? Some USB chains are even more expensive.

 

BUT...

 

...this is all moot for me because in my system the sound quality is just magic. I thought that is why we are all here.

[joelha]

The first measure was to replace the onboard ethernet interface by a special Intel Ethernet-Server-Adapter. This improved the average latency, but the latency still was not stable.

 

Hey Mattias,

 

Very interesting post.

 

Specifically, which Intel ethernet adapter did you choose?

 

Joel

[earnmyturns]

I'm not familiar with the details of the DLNA/UPNP protocol, apart from bad experiences when using it and I kept far away from it eversince, but others with more knowledge about it condemn it to burn in hell for ever.

 

I can imagine that the content of what is transfered in the IP-packages requires a different kind of rendering at the receiver end. We already know from experience that more CPU activity at the renderer that is connected to the DAC, is bad for sound quality. So that could also be an explanation apart from the possibilities you already raised.

UPnP/DLNA has worked great for me except when using a some bad implementations (early Naim firmware, for instance). Some people have persistent trouble with it, but then there are people who have trouble with other digital audio protocols. Simply, there are so many possible combinations of source and destination hardware and software that it is almost certain that people will hit the bad combos and attribute it to the protocol when the real problem is in incorrect implementations of the protocol.

 

As to your second point, the differences in computation load between different IP-based protocols are fairly trivial. After all, these protocols (TCP/IP in DLNA's case, RTP for AES67) were developed when computers were way, way less powerful than they are today. Even a teeny ARM device today has way more memory and CPU than the hardware those protocols were designed for. It's quite possible that some renderers have incorrect implementations of some protocols (as I noted above, I saw that in early Naim firmware), and pro renderers may be more extensively tested (their makers would not last long in business if they did not make a solid product), but everything I know and have experienced in networking since the dawn of TCP/IP tells me that proper implementations of any Ethernet protocols should be transparent with respect to SQ. My guess is that the people who report superior results from RedNet devices have lucked into a sweet spot in how the clocked bitstream from the device to the DAC interacts with their DAC through the particular interconnect they are using. Great for them, but not evidence that a particular Ethernet protocol is responsible.

[jabbr]

Many of your previous points may be valid and reasonable theory. I agree that the REDnet devices are definitely overkill in terms of functionality and may be initially harder to set up for some. In terms of simplicity for the number of devices needed it is very simple. Ethernet cable>REDNet device> digital cable of choice> DAC. How many of us that have set up good sounding USB chains can say that? Some USB chains are even more expensive.

 

BUT...

 

...this is all moot for me because in my system the sound quality is just magic. I thought that is why we are all here.

 

It all comes down to the sound

 

Maybe a tutorial for config of QoS for Ravenna for the home network would be helpful (I like that solution much better than multi homed networks)

[Matty70]

It all comes down to the sound

 

Maybe a tutorial for config of QoS for Ravenna for the home network would be helpful (I like that solution much better than multi homed networks)

 

Here you find a tutorial for setting up a switch for RedNet.

 

This might probably work for Ravenna too.

[Matty70]

Hey Mattias,

 

Very interesting post.

 

Specifically, which Intel ethernet adapter did you choose?

 

Joel

 

Thanks Joel

 

This is the ethernet adapter I bought:

 

Energy-Efficient Ethernet Evolves Networks

 

 

When I still had lateny problems in my network I was considering to buy the RedNet PCI-Card.

But this card is really expensive and so I tried it first with the above mentioned adapter in the hope that it makes a difference to the onboard ethernet adapter.

[Aleg]

Here you find a tutorial for setting up a switch for RedNet.

 

This might probably work for Ravenna too.

 

In the latest release notes of the Ravenna Virtual Sound Card it says it only does MultiCast at the moment and UniCast will be added at a later point. This is probably what Chris Connacker used.

This then also requires that IGMP-snooping is configured to prevent drowning the network.

Yes, the manual for the Dante configuration can be used for QoS if you have managed switches that allow for that. The best manual is from audinate itself which explains how to setup IGMP snooping from pg 58 onwards in this manual: https://www.audinate.com/sites/default/files/PDF/advanced-dante-networking-avnw-2015-audinate.pdf

 

But all this IGMP snooping and QoS configuration is not needed for AOIP in a home setting when using Dante RedNets and keeping to the default Unicast settings.

 

Ravenna has still some work to do on their virtual sound card.

It would be best if the Dante DVS would act as a proper AES67 device, it could then be used for any AOIP that was AES67 compliant. Unfortunately Audinate has no plans to make the DVS a proper AES67 device. There is a possibility that Audinate will upgrade their PCIe cards to proper AES67 devices, which could then be used to front any other AES67 device.

 

Cheers

[gldgate]

One more nice thing about the D16 is that it seems fairly impervious to my audio tweaks. I've tried different power cords, Ethernet cable and AES cables to absolutely no audible difference. Where do I return my audiophile membership card?

[dbrulhart]

Is the Ravenna setup for multicast streaming?

Can you set it to unicast, instead?

 

I had the same issue with my Rednet 3 flooding my Asus RT-AC56U router's wifi. The problem was that I had a multicast flow enabled on the transmit side (from the Rednet 3 to the whole network) and my router was passing multi-cast packets over to Wifi devices.

 

In the router's manual, there's an option to disable Wifi multi-casting. Alas, the option is not present in the newer firmwares.

 

Disabling that transmit multi-cast from the Rednet device solved the issue. It wasn't used anyway. I set it up as a test and forgot about it.

 

For everybody's interested, Merging has released recently a new firmware and drivers bundle for NADAC that is now supporting Unicast as default. This solves all problems observed in the early versions of NADAC on home networks. No more managed switches are required for normal operation of NADAC on "sensible" networks and no more perturbations of the network are observed when NADAC is operating, nor audio artifacts on the NADAC outputs.

 

Multicast support is still available for those enjoying professional grade networks (meaning isolated from heavy internet usage, wifi, etc... typical family usage of home networks) and can still use NADAC in these conditions as an option in the driver.

[dbrulhart]

In the latest release notes of the Ravenna Virtual Sound Card it says it only does MultiCast at the moment and UniCast will be added at a later point. This is probably what Chris Connacker used.

This then also requires that IGMP-snooping is configured to prevent drowning the network.

Yes, the manual for the Dante configuration can be used for QoS if you have managed switches that allow for that. The best manual is from audinate itself which explains how to setup IGMP snooping from pg 58 onwards in this manual: https://www.audinate.com/sites/default/files/PDF/advanced-dante-networking-avnw-2015-audinate.pdf

 

But all this IGMP snooping and QoS configuration is not needed for AOIP in a home setting when using Dante RedNets and keeping to the default Unicast settings.

 

Ravenna has still some work to do on their virtual sound card.

It would be best if the Dante DVS would act as a proper AES67 device, it could then be used for any AOIP that was AES67 compliant. Unfortunately Audinate has no plans to make the DVS a proper AES67 device. There is a possibility that Audinate will upgrade their PCIe cards to proper AES67 devices, which could then be used to front any other AES67 device.

 

Cheers

 

Merging has two versions of the Ravenna Virtual Sound Card (well more than that actually), but mainly one for the professional side, still in multicast, with much more streams supported, and a consumer one, now operating in unicast (or multicast optionally).

 

There are definitely plans for releasing the unicast support in the professional Virtual Sound Card at some point in the future, however Merging is currently addressing other priorities.

 

AES67 is one of them, Merging released at the beginning of the year a free AES67 Virtual Sound Card that will allow connecting to Dante as soon as their AES67 support will be released, however only at 44.1/48 kHz for the time being. But Merging is following this thread very closely.

 

On thing that is important to notice though, is that Ravenna is the only open protocol supporting sampling rates up to DXD/384kHz, and more important DSD. The currently available Ravenna Virtual Sound Cards, both using multicast for the professional world and unicast for the consumer world do support DSD up to 11.2 (for now), as standard in the protocol, without cheating with DoP. These VSC are available for both Mac and Windows and soon for Linux.

 

AoIP is a complexe beast with multiple heads, that exists for decades on thousands of flavors, however Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS.

 

So, Aleg, thank you very much for your very important post, and you're perfectly right Ravenna has still some work to do on their Virtual Sound Card, but this work is actually being done, and very actively. We're progressing step by step, adding the necessary features for each market and applications as they're required, but the motto is simple, networked high resolution for all, and we're not that far.

 

Cheers,

[Aleg]

Merging has two versions of the Ravenna Virtual Sound Card (well more than that actually), but mainly one for the professional side, still in multicast, with much more streams supported, and a consumer one, now operating in unicast (or multicast optionally).

 

There are definitely plans for releasing the unicast support in the professional Virtual Sound Card at some point in the future, however Merging is currently addressing other priorities.

 

AES67 is one of them, Merging released at the beginning of the year a free AES67 Virtual Sound Card that will allow connecting to Dante as soon as their AES67 support will be released, however only at 44.1/48 kHz for the time being. But Merging is following this thread very closely.

 

On thing that is important to notice though, is that Ravenna is the only open protocol supporting sampling rates up to DXD/384kHz, and more important DSD. The currently available Ravenna Virtual Sound Cards, both using multicast for the professional world and unicast for the consumer world do support DSD up to 11.2 (for now), as standard in the protocol, without cheating with DoP. These VSC are available for both Mac and Windows and soon for Linux.

 

AoIP is a complexe beast with multiple heads, that exists for decades on thousands of flavors, however Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS.

 

So, Aleg, thank you very much for your very important post, and you're perfectly right Ravenna has still some work to do on their Virtual Sound Card, but this work is actually being done, and very actively. We're progressing step by step, adding the necessary features for each market and applications as they're required, but the motto is simple, networked high resolution for all, and we're not that far.

 

Cheers,

 

 

Hi dbrulhart

 

Thank you for your postings that gives us more insight in the Ravenna products from Merging. Very interesting developments indeed.

Is it correct that the "Merging RAVENNA/AES67 Virtual Audio Device - STANDARD Installer" is only available for OSX, or am I overlooking the proper link for Windows?

I immediately applied for the temporary download access of course, but fail to see the Windows version of the Virtual Audio Device.

 

Thanks for your help.

[jabbr]

...

 

On thing that is important to notice though, is that Ravenna is the only open protocol supporting sampling rates up to DXD/384kHz, and more important DSD. The currently available Ravenna Virtual Sound Cards, both using multicast for the professional world and unicast for the consumer world do support DSD up to 11.2 (for now), as standard in the protocol, without cheating with DoP. These VSC are available for both Mac and Windows and soon for Linux.

 

...

Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS.

 

...

Ravenna has still some work to do on their Virtual Sound Card, but this work is actually being done, and very actively. We're progressing step by step, adding the necessary features for each market and applications as they're required, but the motto is simple, networked high resolution for all, and we're not that far.

 

Terrific to hear this. Will address my concerns. Of course we also expect native DSD512 and I know the hardware is capable of handling that

[joelha]

Thanks Joel

 

This is the ethernet adapter I bought:

 

Energy-Efficient Ethernet Evolves Networks

 

 

When I still had lateny problems in my network I was considering to buy the RedNet PCI-Card.

But this card is really expensive and so I tried it first with the above mentioned adapter in the hope that it makes a difference to the onboard ethernet adapter.

 

Great information, Mattias.

 

Can't wait to try it.

 

Thanks very much.

 

Joel

[Aleg]

..... will allow connecting to Dante as soon as their AES67 support will be released, .....

 

Hi dbrulhart

 

As far as I know (and I have it first hand from Audinate) the AES67 support has already been available since January 2016 for Dante devices based on their Brooklyn II card, so there shouldn't (have to) be any issues on that front.

 

Cheers

[Superdad]

Merging has two versions of the Ravenna Virtual Sound Card (well more than that actually), but mainly one for the professional side, still in multicast, with much more streams supported, and a consumer one, now operating in unicast (or multicast optionally).

 

There are definitely plans for releasing the unicast support in the professional Virtual Sound Card at some point in the future, however Merging is currently addressing other priorities.

 

AES67 is one of them, Merging released at the beginning of the year a free AES67 Virtual Sound Card that will allow connecting to Dante as soon as their AES67 support will be released, however only at 44.1/48 kHz for the time being. But Merging is following this thread very closely.

 

On thing that is important to notice though, is that Ravenna is the only open protocol supporting sampling rates up to DXD/384kHz, and more important DSD. The currently available Ravenna Virtual Sound Cards, both using multicast for the professional world and unicast for the consumer world do support DSD up to 11.2 (for now), as standard in the protocol, without cheating with DoP. These VSC are available for both Mac and Windows and soon for Linux.

 

AoIP is a complexe beast with multiple heads, that exists for decades on thousands of flavors, however Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS.

 

So, Aleg, thank you very much for your very important post, and you're perfectly right Ravenna has still some work to do on their Virtual Sound Card, but this work is actually being done, and very actively. We're progressing step by step, adding the necessary features for each market and applications as they're required, but the motto is simple, networked high resolution for all, and we're not that far.

 

Cheers,

 

Hi: Enjoyed reading your posts dbrulhart. You clearly have some understanding of the status of AES67, etc.

 

As many here know, while I am enthusiastic about the potential and promise of more Ethernet DACs eventually arriving, I continue to watch for the key change that will actually make AES67/Ravenna "open" enough so that DAC designers--who don't want to become s/w firms or reinvent the wheel--will have the tools to produce a solution. I refer of course to "virtual sound card s/w."

 

[As this is the Focusrite REDNet thread, I want to be clear to separate my concerns about AES67 from the current and complete Dante DVS solution available for the REDNet Ethernet>S/PDIF boxes. I am happy for those folks enjoying that fine set up, though I myself do not see S/PDIF as the ultimate interface to a DAC (would rather see Ethernet>I2S interfaces built in, which leads me to my next questions).]

 

You discussed a bit about Merging's intentions for the multi-platform Ravenna Virtual Sound Card software and drivers which they spent a lot of time developing, and which to-date only operates with their hardware.

 

You wrote "Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS." Are you saying that Merging is going to begin licensing their VSC and drivers to other manufacturers, including those who might OEM newer AES67 modules (such as Covelez BACH)?

 

Such would be big news, and rather important. You and Aleg said "Ravenna has still some work to do on their virtual sound card," but of course "Ravenna" is not an entity (unless you consider ALC NetworX, the lead firm hosting the AES67/Ravenna website to be in charge), and while both the standard and some AES67 OEMable modules exist (including Covlez BACH and Audinate's now AES67-supporting Brooklyn II), nobody is yet providing licensable virtual sound card s/w for those modules. And THAT's what is keeping hi-fi audio DAC manufacturers from offering AES67 Ethernet inputs on their products.

 

For example, DAC maker Ayre, who just released their flagship new DAC would have jumped into AES67 for its Ethernet input--rather than the DLNA (with coming Roon support) renderer board they chose--had licensable, current, and supportable VSC s/w been available. (Really, it should become part of the operating systems--so that it gets updated as the OSs do--but hey, its 2016 and Microsoft still does not have UAC2 support in Windows 10.)

 

So if there is real news out there about the situation changing, please do share it with us. I'd love to see Merging open and give away (or license) their VSC code and allow it to be used on hardware other than their own. But until they or someone else does, I'll continue to think of AES67/Ravenna as only open hardware spec.

 

Best,

--Alex C.

 

P.S. Sorry to the group for the diversion away from Focusrite, the topic of this thread. But this is the only active AOIP thread here at CA now, and dbrulhart implied something that could have broad impact if true.

[The Computer Audiophile]

Thanks for the info Dom.

[Aleg]

...

You discussed a bit about Merging's intentions for the multi-platform Ravenna Virtual Sound Card software and drivers which they spent a lot of time developing, and which to-date only operates with their hardware.

 

You wrote "Merging is committed to release usable technology, products and drivers, based on open protocols, allowing for multiple manufacturers to be OPENLY INTEROPERABLE at ANY RESOLUTION on VARIOUS MARKETS." Are you saying that Merging is going to begin licensing their VSC and drivers to other manufacturers, including those who might OEM newer AES67 modules (such as Covelez BACH)?

 

....

 

Hi Alex

 

W.r.t the Merging Virtual Sound Card, the Merging website states the existence (and actually allows download of) their software.

The Merging Technologies RAVENNA/AES67 STANDARD Virtual Audio Device edition is free of charge and intended for owners of any RAVENNA and/or AES67 multi-cast device.

 

It has (as of yet) limitations that would prevent wide-spread use, (such as support for 44 & 48 kHz only, but there exists a Premium version for use with the Merging HORUS and HAPI, so who knows what can be negotiated). But I can find only the OSX version, though IIUC there should also be a Windows version in existence and Linux version under development.

 

Comparisson of Standard vs Premium version of Merging Sound Card software:

Mac OS X: RAVENNA/AES67¹ Virtual Audio Device Specifications:

 

PREMIUM edition: Bundled free for owners of a Merging Network Interface

 

STANDARD edition: Free with any RAVENNA/AES67 Hardware compatible device. Downloadable here

 

I would also consider this a giant leap if their software would become generally available or licenseable for other parties with AES67 products.

 

I hope to hear more from dbrulhart about the Merging SOund Card s.w

[Serge_S]

Great information, Mattias.

 

Can't wait to try it.

 

Thanks very much.

 

Joel

 

Audinate does not recommend using EEE:

 

https://www.audinate.com/resources/faqs then filter switches.

[Aleg]

Audinate does not recommend using EEE:

 

https://www.audinate.com/resources/faqs then filter switches.

 

So? I don't understand the point you are making?

 

EEE reduces responsiveness of the switch required for the Real Time AOIP.

 

Audinate has several requirements for the switches to be used in pro-audio AOIP settings (but not everybody uses Pro-Audio level networks):

 

What is the minimum requirement for switches in a Dante network?

 

All Ethernet switches are capable of working with Dante. However, please be aware that there are some features on some kinds of switches that will allow you to build larger and more reliable Dante networks.

 

While Gigabit switches are recommended, 100Mbps switches may be used in limited scenarios.

 

For channel counts of 32 or more, Gigabit switches are essential. QoS is required when using Dante in networks that have 100Mbps devices. QoS is also recommended for Gigabit switches on networks that share data with services other than Dante.

For lower channel count (<32) applications, a 100Mbps switch may be used as long as it supports proper QoS, and QoS is active. The use of 100Mbps switches without QoS is not recommended or supported.

What features are important when purchasing a switch?

 

Dante makes use of standard Voice over IP (VoIP) Quality of Service (QoS) switch features, to prioritize clock sync and audio traffic over other network traffic. VoIP QoS features are available in a variety of inexpensive and enterprise Ethernet switches. Any switches with the following features should be appropriate for use with Dante:

 

Gigabit ports for inter-switch connections

Quality of Service (QoS) with 4 queues

Diffserv (DSCP) QoS, with strict priority

A managed switch is also recommended, to provide detailed information about the operation of each network link: port speed, error counters, bandwidth used, etc.

https://www.audinate.com/resources/networks-switches