Jump to content
IGNORED

Focusrite REDNet


Recommended Posts

On that note, what do folks think about why DLNA managed to get such an early hold in home network audio? Was it lack of alternatives? Was it better coordination or OS s/w support by the consortium? Was it because the the big CE and TV companies embraced it? I honestly don't know because I have pretty much eschewed UPnP/DLNA the whole time. But I think we AOIP enthusiasts (and AES67 supporters) might do well to look to the past successes and failures of DLNA to chart a course.

 

UPnP got where it is because big consumer electronics companies just included it in their products and formed the DLNA to make them actually compatible. I was involved in some of that stuff too on my Nokia days...

 

But overall, I wouldn't even talk about UPnP and AES67 in a same forum posting, because the two are so different, coming from different worlds and for completely different purpose/goals and requirements. The only common denominator I can see is that both can do audio. :D

 

UPnP/DLNA is essentially:

1) Web server with bunch of media files

2) Player software that can play a file from the web server

3) Control point software that tells player what to play from the server (URL)

(and due to this architecture, there are completely idiotic things in the implementation such as seeking)

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Lack of alternatives at the time, I'd say, riding on the back of the much larger home network video market. Also UPnP/DLNA uses the network merely to provide access to (audio) files, ie file streaming, derived from traditional computer client/server concepts. This is different to the more alien task (re traditional computing) of using the network as a conduit for the real-time digital audio signal itself, as required by AOIP and AES67. So UPnP/DLNA arguably makes a much simpler use of the network, with the audio file player being at the receiver side of the network, as opposed to the source side of the network with AOIP and AES67.

 

Well, the RTP/RTCP/RTSP/SDP protocols (AFAIK used by AES67/RAVENNA) already existed and were used for example to provide audio and video calls over internet when combined with SIP protocol already at that time. We implemented also those to the mobile phones (our first productized internet video call stack was on 770 Internet Tablet). PTPv2 used for clock synchronization is a bit newer standard and was mostly used first together with AVB standard (which is common for example in automotive segment).

 

From my point of view, it is only about different industry groups doing different stuff for different purposes with different requirements and especially wanting to make their own standard instead of using someone else's (political part of the story).

 

Technically, UPnP was never designed for things like:

1) Recording content

2) Doing low-latency live processing (audio from microphones on a stage to a mixer and from there to the PA system)

 

 

P.S. DLNA is just a consortium to agree on list of common formats - required/optional for interoperability. Because UPnP standard itself doesn't say anything about the exact content formats and codec features. DLNA then specifies things like "renderer supporting video playback shall support AVC Base Profile 640x480 @25fps in MPEG-4 Program Stream" and "renderer supporting audio playback shall support MPEG-1 Layer III audio at 44.1 kHz 16-bit stereo".

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
  • 1 year later...
8 hours ago, mourip said:

This could be the real breakthrough for AOIP.

 

Dante is more for pro-audio. For audiophile use it can be tricky one because it distributes clock over ethernet for the purpose of synchronizing multiple A/D and D/A converters and other devices. And Dante doesn't support DSD or PCM sampling rates above 192 kHz. Ravenna which is variant of practically same protocol (AES67) does support DSD and high rate PCM.

 

For audiophile use, clock-less protocols where DAC always has the master clock are easier and better. Unless you want to synchronize multiple DACs (synchronous multi-room case).

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
Just now, Kal Rubinson said:

..... or to use 3/4 stereo DACs for multichannel.

 

Yes, that too. Although not much point in such, because there are so many multi-channel converters with 192 kHz PCM capability...

 

Like for Dante, the Focusrite RedNet A16RRedNet 1 or RedNet 2.

 

Of course if you need more than 16 channels, you can stack those up to 128 channels.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
3 minutes ago, Kal Rubinson said:

but not so much for the home market.

 

Why would it need to be "home market"? Dante is not for home market in first place. It is designed for pro-audio use cases just like Ravenna and other AES67's.

 

With Merging Hapi you can get 16 channels of DXD/DSD256, and with Merging Horus you can get 48 channels of DXD/DSD256...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
10 hours ago, Kal Rubinson said:

Understood but I am hoping for one or more of the AES67 variants to be adopted for it.

 

Merging already has their NADAC. But I'd rather see something that doesn't need clock distribution on the network and special network adapters to properly support that. I'd prefer protocol that is less complex and would be more geared towards home playback use cases. Otherwise Mac users can have only limited capabilities, since there are no PCIe slots on Macs anymore and I haven't seen anybody making special Thunderbolt ethernet-adapters yet although such thing is doable. This Focusrite RedNet adapter works directly only on Windows PCs:

https://pro.focusrite.com/category/audiooverip/item/rednet-pcier

Otherwise you need yet another box for doing Thunderbolt-to-PCIe.

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
6 hours ago, mourip said:

I have been using a Focusrite D16 with a Mutec 3+ USB for reclocking and a Mutec REF10. These are all pro-audio devices but I am getting far better sound from my system than when I had a tweaked out USB chain. It has not been cheap but it brings real magic to PCM. Who cares if they were intended for pro-audio?

 

I have owned 4 Saber DACs that played DSD and I was not too impressed. I am getting far more enjoyable and detailed sound from my present system playing 24/192 to my Yggy via AES. I believe in being open minded about what really works. I would not discount pro-audio just because it is not intended for home use. Why not take the best of what is available?

 

Have you actually measured jitter performance of that combination from the DAC output? I rather not have ASRC devices on the way and that sounds like unnecessarily complex setup instead of using just plain D16.

 

I use my own NAA protocol, so of course I'm biased towards it. But I want multichannel DSD and such...

 

6 hours ago, mourip said:

CA will die on the vine if we all just take the same path and refuse to consider new ideas. Lets be about experimentation and mindset breaking...

 

Where did I refuse to consider new ideas? I just say that I'd rather use something that is technically more suitable for my use cases than what Dante/RedNet can offer today. So yes, I'm certainly about mindset breaking.

 

Technically Yggdrasil via AES is as old technology as something can get... ;)

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
4 hours ago, dbrulhart said:

The clock distribution is part of the RAVENNA (PTP2) and Dante protocol (PTP1) and is totally transparent and not complex. No special adapters are needed.

 

Hi Dominique,

 

I know there are some adapters that have hardware support for PTP, like the Focusrite RedNet card. Without that hardware support, the network clock accuracy suffers when it is implemented in user space. For home use I don't see point in distributing clock on the network at all (my NAA protocol doesn't).

 

4 hours ago, dbrulhart said:

On the pro market (Horus/Hapi) we use RAVENNA/AES67 in multicast mode, and this indeed requires being careful with the network not to impact too much other equipment on this network.

 

However on the home market (NADAC) we use RAVENNA in unicast mode, which works perfectly on any network, with any of the shelf switches or network adapters.

 

OK, good to know. How is the master clock in each case determined? And how is packet loss for example in wireless networks managed? I have not heard much reports from people using RAVENNA over domestic WiFi, although I have some customers using Hapi and NADAC. Since I've understood that both use RTP-over-UDP instead of TCP stream. And streams are controlled by PTP timing instead of flow control with RTCP?

 

I know the fun of dealing with RTP-based streams because we implemented such when I was still working at Nokia, for voice and video calls over internet. Lot of that technology is still in use on 4G VoLTE. Not to even mention NAT-traversal challenges which of course don't exist in local networks. Newer protocols have systematically moved to use TCP instead.

 

4 hours ago, dbrulhart said:

And all this works natively even for multichannel DSD (DSD is part of RAVENNA, as opposed to Dante) without any complexity involved.

 

That I obviously know and stated earlier... ;) That's why I see RAVENNA as better option than Dante, also for higher PCM rates.

 

4 hours ago, dbrulhart said:

Simple ;-)

 

I look it from developer point of view as complexity of the protocol stack and stream management. For me it looks very complex for home audio use.

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
3 minutes ago, mourip said:

I hope that I am following your point but I do not know of any posters who have mentioned purchasing Focusrite's PCIe adapter although some claim good results with high end Intel cards. Even Focusrite states that it is only useful if you need to support a large number of Dante devices.

 

I believe some high-end adapters have PTP hardware support, but I don't remember details on that.

 

They say that the achievable latency is about 4x higher with standard ethernet adapter compared to one with PTP hardware support.

 

6 minutes ago, mourip said:

I imagine you could use Thunderbolt add-on adapter to add a second ethernet port to a MAC also or Apple's own USB to ethernet dongle.

 

Googling Thunderbolt to PCIe brings up Sonnet and HighPoint that sell Thunderbolt to PCIe breakout boxes.

 

I just have some doubts if the Apple's Thunderbolt-to-Ethernet is "high end" NIC model.

 

But yeah, modern Apple way you can do a lot by adding lot of dongles, especially if you obtain some dongle-connection-dongles. Like with my iPhone 7, if I want to used wired headphones or external DAC and charge the phone at the same time... ;)

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
2 minutes ago, ferenc said:

Actually Dante can be used at home for multi room installations easily, there are even wall plates available integrated with Dante/AES67. 

 

https://www.atterotech.com/products/dante-wall-plates

https://www.atterotech.com/products/aes67-wall-plates

 

I know there are quite a few other multi room solutions as well, Dante/AES67 available for wall plates it means pricing can be changing for the better in the not so distant future. 

 

Looks neat, but I have to wonder how many audiophiles would accept the DAC integrated into the wall socket... :D

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
  • 8 months later...

Note that multi-homed (computer with more than one network interface) setups are potentially very problematic. For running internet firewall machine, having two interfaces makes sense, for running regular network node, it doesn't.

 

There is no advantage in using direct connection with networking gear, it usually causes much more problems than it solves. Networking gear is fully equipped to deal with different types of traffic on a single interface with support for QoS etc. Just use a good quality gigabit ethernet switch and your are fine...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
5 hours ago, mourip said:

Thanks for the input. My D16 has two network ports and I do have the option to hook my LAN link up to it. I did have it set up that way originally but my thinking was to limit any traffic between the server and D16 to just audio.

 

I meant removing or disabling second ethernet interface from the computer and connecting both the computer and Dante device to the same gigabit switch with one cable and neither one having any other connections. It's like a star with the switch in the middle. When setup this way, D16 won't see any other than audio traffic either. Your computer's port will have audio and it's own internet traffic mixed, but that's not a problem.

 

Point of having a switch is that each device sees only traffic intended for them, nothing else, even though they participate in the same network...

 

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment
  • 2 weeks later...
  • 2 weeks later...
4 hours ago, mourip said:

I left both of my ethernet connections connected to a Cisco SG200 which is powered by an LPS and has its LAN connection provided over fiber optic to ensure ground isolation.

 

By the way, it likely has 802.3x Ethernet flow-control disabled by default. For my network audio stuff, people were having issues with this switch, until we realized that the flow-control support was disabled by default. After enabling it all the problems disappeared. You could try enabling that and see if it changes anything. At least it doesn't cost anything to try... :)

 

These switches discard flow-control packets is the support is disabled, sometimes causing excessive packet loss. This shouldn't matter for protocols like AES-67 / RAVENNA / Dante, but still...

Signalyst - Developer of HQPlayer

Pulse & Fidelity - Software Defined Amplifiers

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...