Dante Protocol Networked Audio

@dsreyes

So based off reading that thread there are two things I believe are occuring:

  1. Adrian Knoth (adiknoth) is likely using the driver and card from FourAudio (I believe he is the one that initially pointed me in their direction)
  2. Dell Green likely has a developer kit from Audinate (Brooklyn II Kit and Card, which I believe has a Linux SDK IIRC)

Audinate has flat out told me that they have no intention of releasing a Linux driver, that was years ago mind you so maybe things have changed, but I doubt it. My suspicion is that Dell Green is using the development kit but I do not know for certain. It would be worth contacting him I suppose just in case so I just added a comment there to see if he responds.

      Seablade

@seablade

I’ll keep an eye on that and ask around. Thanks for responding

For everybody’s interest, Merging Technologies provides Windows/ASIO and MacOS/CoreAudio drivers and Virtual Sound Card for Ravenna since many years.

A MacOS/CoreAudio AES67 VAD has been released early this year and is available free of charge, please check http://www.merging.com/

Now, to complete the panorama, Merging is about to release a Linux ALSA driver/VAD for Ravenna/AES67, a few distributions are already in advanced testing. As a Linux/ALSA doesn’t deploy as easily as a Windows/Mac driver, anyone interested can contact us on http://www.merging.com/contact or directly to aes67@merging.com for discussing availability and deployment options.

That may allow an easy bridge to Dante since they are finally AES67 compatible.

Dominique

@dbrulhart

This is great to hear, sadly since Allen and Heath hasn’t updated the firmware on their dante cards yet, there is no AES67 support there yet that I know of, so knock off two of my systems there(Possibly more would have to think). I have to check on my Yamaha CL system though to see whether they support AES67 or not.

     Seablade

I concur with seablade that this is great to hear. I don’t currently have the budget to change to AES67 hardware, but it does open up interesting possibilities for future upgrades.

How about the MOTU AVB interfaces? They have builtin 48 channel mixers for their devices and they just released firmware to use AVB as a separate interface. I’ve been reading up on the development for the Intel i210 cards that supports AVB on linux and thought this might be a possibility in the near future.

A very late reply to the Dante thing… Things didn’t get much better on Linux. They however did get better in the world of hardware, not so much im terms of PC hardware, but in terms of mixing consoles, breakout boxes, stage boxes, wireless microphone receivers etc. – Yamaha even uses only Dante on their recent digital mixing consoles and stage boxes and nothing else.

The Dante PCIe card is offered by several vendors, it looks more or less the same in all pictures. Apparently, the variant called LX-Dante by DigiGram comes with ALSA drivers: LX-DANTE - Support | Digigram

RME has a USB DigiFace Dante at around the same price point that should work in class-compliant mode, then not offering TotalMix. Additionally, it can convert MADI to DANTE standalone.

There’s the Dante Aviom 2x2 USB adaptor that should work for simple purposes.

So far I used none of these. I used the Dante Virtual Soundcard on OS X using MixBus for testing. This does a good job, but it doesn’t work on my old MacBook pro with any Dante latency below 11msec (4msec and 1msec are the other options). Also it seems to be pretty at its limits at 16 channels at 48khz. In Dante Controller you can get a statistics of dropped audio frames and it is not promising. I got dropouts when using 16 channels at 4msecs, I was okay at 11msecs.

So my conclusion for now is that albeit the Dante Virtual Soundcard would be really good to have on Linux, it probably wouldn’t be good enough for a 24channel/96khz recording studio setup. I’d like to use it to feed stereo playbacks into my digital mixing console without going analog.

Audinate recently announced a Dante embedded platform that they say will be available for Linux, too. In theory, and to my limited knowledge, this would allow to develop something like a Jack sink/source for Dante, but it might well be that legal restrictions wouldn’t allow for it.

Some people report AES67 to work well on Linux, but apparently it is not as easy to set up. Dante is really smooth to get going once you’ve understood a few basic things. Note that ES67 interoperability is a feature of the Dante devices. So far all recent devices I’ve seen would offer me to switch on AES67 mode in Dante Controller, older ones might not provide this. Note also that Dante Virtual Soundcard on Windows and OS X will not provide AES67, so you’d have to go entirely AES67 on a mixed PC platform setup.

Uh that sounds like very poor performance. I have used DVS with 64 channels @10mS without issue repeatedly on a variety of older Mac hardware, and done live processing at lower latencies, but not sure if I have done large channel counts at lower latencies or not.

I would strongly disagree with this statement for the record. While 96k is unusual for most Dante systems it is not out of the question, for instance one of the Digico systems I put in recently can run Dante at 96k and track like that.

Technically that was announced years ago (Got announced last time I attended Infocomm, which was pre-COVID by I believe a couple years), and I believe exists and is in use. For instance the QSYS system that runs Linux also has a Dante software license you can purchase, which indicates to me that it may well already be in use. The problem of course being that they charge a licensing fee, and don’t seem to be interested in making a native DVS client, but letting others develop products off it to put in embedded systems that run linux (ie. that QSYS system I mentioned).

Seablade

The Ravenna driver which Merging Technology wrote is not maintained for kernel updates very well, but someone else has forked the driver to patch for newer kernels, and also created a GPL user space daemon to replace the binary only daemon that Merging provides for their original driver.
Andrea Bondavalli AES67 daemon and driver fork

I have had that AES67 daemon working with a Yamaha Dante stagebox in AES67 mode, but the Dante controller software that you have to use to configure Dante devices will not run under WINE, so you still need a Windows machine to set everything up (presumably an OS X machine would work as well).

I would prefer to get a native Ravenna interface, those almost universally have an embedded web server for configuring so you do not need any proprietary control applications, but so far Ravenna devices are still relatively expensive and relatively rare compared to Dante devices. I found the Yamaha interface for US$600 on eBay, the equivalent Ravenna device would be a Merging Hapi which goes for anywhere from US$4000 to US$5000 on Reverb. Out of my budget for the foreseeable future.

Seablade, I strongly appreciate your disagreement on the DVS on OS X. :slight_smile: I’m just reporting my findings on an MacBook Pro 2017 (version with two Thunderbolt ports). Performance might also depend on the NIC in use, so Mac computers with different USB NICs or even built-in ones might be better. Which indicates a typical problem, while you could force realtime priorities on (PCIe) audio interfaces, it may be harder to do so on network traffic.

The Dante Virtual Soundcard (DVS) seems to be quite reliable on Windows embedded. I regularly encounter a Newtek Tricaster video switcher which internally is a Windows embedded system apparently running on DVS. No Dante issues so far.

In general it is a good idea to check the dropout/latency statistics view in Dante Controller when setting up a new system.

A bridge to ALSA or (better) Jack using Audinate’s embedded code as a payware product would make sense to me. That would involve paying fees to Audinate by the manufacturer of such a bridge. Not unlikely for the QSYS system to be quite related to that idea. Quite naturally I prefer open source, but then again, especially when not working on a fixed setup but on a mobile one, easy of use is key.

It is also unfortunate that Dante Controller is not available for Linux, even though large parts of it are written in Java. Exploring its JARs however reveals some platform dependent binary code.

So my Dante AVIO USB by Audinate arrived today, the old version with the USB-A connector. I’m still on Kubuntu 18.04 with kxStudio PPAs. The device showed up right away, I could run Jack on it but I was not very pleased to find that it would do plenty of digital clicks when talking to other Dante gear. Sounds exacatly like the AVIO USB is running a different 48khz clock than the rest of the system and every now and then the buffers don’t match any more. (Dante Clock Master is my SQ-5 digital console, the heart of my Dante setup.)

Turns out that I need to re-configure my digital console in Dante Controller in order to make the Avio work with it. (See Dante Troubleshooting : Aviom Blog)

Turns out that my ESI Planet 22cc Dante box does not have this „Enable Sync to External“ so it will probably not operate together properly with the Avio USB.

So this device is apparently not a reliable solution for hooking up 2x2 Dante to any PC. The issue is also present on OS X. Or I’m just wrong and it’s not as simple as it used to be. Which would be nice because I’d have a solution then.

(EDIT: It’s not as simple as that, see postings below… well)

What device latency did you configure?
The default Dante latency is just 1ms, which is 48 samples. Difficult for most machines to handle 48 sample buffer size.
You can configure 2ms or 5ms, but 5ms is 240 samples, which is not a power-of-2 size, so some software doesn’t deal with that well.

Will the driver accept buffer sizes larger than that, and handle the buffer management between the host side and network side, or will it force you to use device buffers the same size as the network buffers?

Turns out that the AVIO series needs a different configuration of your entire Dante thing (as stated above, check the link)… after rebooting my Planet 22c, it sounds more promising. I will keep an ear on it in some more testing! This is a bit frightening since neither the DVS nor other gear had needed this so far.

I checked the latency statistics in Dante controller, there were no dropped samples on the network, the peak sample latency was below 0,5msec.

Turns out that when you do something stupid to the AVIO USB, such as disconnecting the network cable, or rebooting its Dante chip from Dante Controller, your PC or Mac will not like this very much (needed Jack/Ardour restart on Linux, and MixBus, which i use on OS X, had to be killed from the command line).

So a 3,5mm TRS jack is really the safer option. :stuck_out_tongue:

Oh and concerning the driver’s buffer, I guess it is independent from the Dante network latency setting. I tested 256, 512 and 1024 samples buffer settings in Jack and it apparently wasn’t of any relevance.

1 ms at 48k would be 16/3 in jack. But even if you went to 256,512 or 1024, I think you would need 3 frames to make things line up. I would test at 32/3 ad move up from there, expecting xruns at that point but tuning might be quicker just looking for least xruns before moving up in latency. Of course maybe you have tried 3 already but I didn’t see it mentioned above. Unfortunately, I have no real experience/hardware with Dante/aes67/avb to confirm.

I think the Dante latency is a different thing from the latency buffer in the ALSA audio drivers.

To my understanding, setting a Dante latency to 4msec, e.g., means that within the network communication, the device will take a maximum of 4msec for its audio frames to reach their destination. If frames take longer, they most likely will be dropped, causing the audio stream to get damaged.

The ALSA driver latency buffer comes on top. It basically levels out the “off-time” in which the OS schedules other things than the program (most times: Jack) using the audio devices, while the audio device constantly delivers data to its output (may it be DA converters, or Dante, or whatever).

So far in my test setup, I never had issues with any dedicated Dante hardware running at 1msec network latency. The Dante Virtual Soundcard on OS X, as mentioned above, is different, it seems to be affected by the performance of your computer, by channel count, and possibly also by the performance of your NIC. (Especially when using USB NICs, like you’re deemd to do on Apple laptops, but I also have seen PC laptops by Terra that won’t go beyond approx. 200mbps on their internal NICs, while my old 2013 Thinkpad kicks their butts at 800 to 900…)

Not quite, the latency setting in network audio protocols refers to the size of the network packets used. As Len pointed out above, 1ms at 48k is 48 samples (or as he put it 16x3), so each network packets would have 48 samples from each channel.

The packing time in the device and the network transit are in addition to that basic packet buffer time, but the packet size does set a minimum latency time. The packet latency also indirectly sets the maximum number of channels that can be grouped together in a stream because of the limit on size of an Ethernet packet.

I’m currently using the Fouraudio PCIE-Card for Dante on Linux. So far its a real pain. The promised Drivers are delivered as binary Kernelmodule just for a specific Kernel. You can not longer upgrade your system without mailing to the fouraudio support to provide a new driver. Also fouraudio is no longer supporting anything but Ubuntu LTS and Debian Mainline Kernels.

The stupid part is that there is kind of a DVS for Linux. On some Products like the QSYS Line from QSC (wich are just Intel Computers running a Linuxkernel and a bunch of very nice and functional proprietary code) you can use mainboard Networkports as Dante Interfaces.

Apart from the fact that i will be stuck with whatever kernelversion i am on when fouraudio decides to drop support completely the card just works. The Card itself introduces 1.4ms Latency plus whatever your Computer can handle for Buffer size plus whatever latency you set your Dante environment to (depends on the number of switches between your paticipants).

Has anybody tried the digigram Card? How are they handling the Driver issue? Cause if i understood the fouraudio guy correctly, audinate restricts there Partners to deliver the drivers as binarys only.

The Dante Controller Software runs under wine but is barely usable. Most of the time gui-elements are missing but i was able to patch with it. It is possible to use a VM for this.

Also somebody mentioned the RME Card. Does anybody know how many Channels it does provide in Class Compliant mode?

Which version of Dante Controller and WINE are you using? I was never able to get Dante Controller 4.1.x or 4.4.x to run under wine, it always gave an error about the Dante discovery server(?) not running. I don’t remember the exact error at the moment, but it seemed to imply that the controller application was expecting to find another component running as a Windows service, and could not communicate with that other component.

Can check the Versions on Monday when I’m back at work. But the daemon not found error that you are mentioning is a thing i know well from Dante Controller on MacOS. So perhaps it is not a wine problem…